* [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
Hi,
This series adds a new SPI driver using the spi-mem interface for the
Aspeed static memory controllers of the AST2600, AST2500 and AST2400
SoCs.
* AST2600 Firmware SPI Memory Controller (FMC)
* AST2600 SPI Flash Controller (SPI1 and SPI2)
* AST2500 Firmware SPI Memory Controller (FMC)
* AST2500 SPI Flash Controller (SPI1 and SPI2)
* AST2400 New Static Memory Controller (also referred as FMC)
* AST2400 SPI Flash Controller (SPI)
It is based on the current OpenBMC kernel driver [1], using directly
the MTD SPI-NOR interface and on a patchset [2] previously proposed
adding support for the AST2600 only. This driver takes a slightly
different approach to cover all 6 controllers.
It does not make use of the controller register disabling Address and
Data byte lanes because is not available on the AST2400 SoC. We could
introduce a specific handler for new features available on recent SoCs
if needed. As there is not much difference on performance, the driver
chooses the common denominator: "User mode" which has been heavily
tested in [1]. "User mode" is also used as a fall back method when
flash device mapping window is too small.
Problems to address with spi-mem were the configuration of the mapping
windows and the calibration of the read timings. The driver handles
them in the direct mapping handler when some knowledge on the size of
the flash device is know. It is not perfect but not incorrect either.
The algorithm is one from [1] because it doesn't require the DMA
registers which are not available on all controllers.
Direct mapping for writes is not supported (yet). I have seen some
corruption with writes and I preferred to use the safer and proven
method of the initial driver [1]. We can improve that later.
The driver supports Quad SPI RX transfers on the AST2600 SoC but it
didn't have the expected results. Therefore it is not activated yet.
This needs more tests.
The series does not remove the current Aspeed SMC driver but prepares
ground for its removal by changing its CONFIG option. This last step
can be addressed as a followup when the new driver using the spi-mem
interface has been sufficiently exposed.
Tested on:
* OpenPOWER Palmetto (AST2400)
* Evaluation board (AST2500)
* OpenPOWER Witherspoon (AST2500)
* Evaluation board (AST2600 A0)
* Rainier board (AST2600)
[1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
[2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
Thanks,
C.
Cédric Le Goater (10):
mtd: spi-nor: aspeed: Rename Kconfig option
dt-bindings: spi: Add Aspeed SMC controllers device tree binding
spi: spi-mem: Add driver for Aspeed SMC controllers
spi: aspeed: Add support for direct mapping
spi: aspeed: Adjust direct mapping to device size
spi: aspeed: Workaround AST2500 limitations
spi: aspeed: Add support for the AST2400 SPI controller
spi: aspeed: Calibrate read timings
ARM: dts: aspeed: Enable Dual SPI RX transfers
spi: aspeed: Activate new spi-mem driver
drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
.../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
drivers/mtd/spi-nor/controllers/Makefile | 2 +-
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
9 files changed, 1369 insertions(+), 3 deletions(-)
create mode 100644 drivers/spi/spi-aspeed-smc.c
create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
--
2.34.1
^ permalink raw reply [flat|nested] 115+ messages in thread
* [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
Hi,
This series adds a new SPI driver using the spi-mem interface for the
Aspeed static memory controllers of the AST2600, AST2500 and AST2400
SoCs.
* AST2600 Firmware SPI Memory Controller (FMC)
* AST2600 SPI Flash Controller (SPI1 and SPI2)
* AST2500 Firmware SPI Memory Controller (FMC)
* AST2500 SPI Flash Controller (SPI1 and SPI2)
* AST2400 New Static Memory Controller (also referred as FMC)
* AST2400 SPI Flash Controller (SPI)
It is based on the current OpenBMC kernel driver [1], using directly
the MTD SPI-NOR interface and on a patchset [2] previously proposed
adding support for the AST2600 only. This driver takes a slightly
different approach to cover all 6 controllers.
It does not make use of the controller register disabling Address and
Data byte lanes because is not available on the AST2400 SoC. We could
introduce a specific handler for new features available on recent SoCs
if needed. As there is not much difference on performance, the driver
chooses the common denominator: "User mode" which has been heavily
tested in [1]. "User mode" is also used as a fall back method when
flash device mapping window is too small.
Problems to address with spi-mem were the configuration of the mapping
windows and the calibration of the read timings. The driver handles
them in the direct mapping handler when some knowledge on the size of
the flash device is know. It is not perfect but not incorrect either.
The algorithm is one from [1] because it doesn't require the DMA
registers which are not available on all controllers.
Direct mapping for writes is not supported (yet). I have seen some
corruption with writes and I preferred to use the safer and proven
method of the initial driver [1]. We can improve that later.
The driver supports Quad SPI RX transfers on the AST2600 SoC but it
didn't have the expected results. Therefore it is not activated yet.
This needs more tests.
The series does not remove the current Aspeed SMC driver but prepares
ground for its removal by changing its CONFIG option. This last step
can be addressed as a followup when the new driver using the spi-mem
interface has been sufficiently exposed.
Tested on:
* OpenPOWER Palmetto (AST2400)
* Evaluation board (AST2500)
* OpenPOWER Witherspoon (AST2500)
* Evaluation board (AST2600 A0)
* Rainier board (AST2600)
[1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
[2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
Thanks,
C.
Cédric Le Goater (10):
mtd: spi-nor: aspeed: Rename Kconfig option
dt-bindings: spi: Add Aspeed SMC controllers device tree binding
spi: spi-mem: Add driver for Aspeed SMC controllers
spi: aspeed: Add support for direct mapping
spi: aspeed: Adjust direct mapping to device size
spi: aspeed: Workaround AST2500 limitations
spi: aspeed: Add support for the AST2400 SPI controller
spi: aspeed: Calibrate read timings
ARM: dts: aspeed: Enable Dual SPI RX transfers
spi: aspeed: Activate new spi-mem driver
drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
.../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
drivers/mtd/spi-nor/controllers/Makefile | 2 +-
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
9 files changed, 1369 insertions(+), 3 deletions(-)
create mode 100644 drivers/spi/spi-aspeed-smc.c
create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
Hi,
This series adds a new SPI driver using the spi-mem interface for the
Aspeed static memory controllers of the AST2600, AST2500 and AST2400
SoCs.
* AST2600 Firmware SPI Memory Controller (FMC)
* AST2600 SPI Flash Controller (SPI1 and SPI2)
* AST2500 Firmware SPI Memory Controller (FMC)
* AST2500 SPI Flash Controller (SPI1 and SPI2)
* AST2400 New Static Memory Controller (also referred as FMC)
* AST2400 SPI Flash Controller (SPI)
It is based on the current OpenBMC kernel driver [1], using directly
the MTD SPI-NOR interface and on a patchset [2] previously proposed
adding support for the AST2600 only. This driver takes a slightly
different approach to cover all 6 controllers.
It does not make use of the controller register disabling Address and
Data byte lanes because is not available on the AST2400 SoC. We could
introduce a specific handler for new features available on recent SoCs
if needed. As there is not much difference on performance, the driver
chooses the common denominator: "User mode" which has been heavily
tested in [1]. "User mode" is also used as a fall back method when
flash device mapping window is too small.
Problems to address with spi-mem were the configuration of the mapping
windows and the calibration of the read timings. The driver handles
them in the direct mapping handler when some knowledge on the size of
the flash device is know. It is not perfect but not incorrect either.
The algorithm is one from [1] because it doesn't require the DMA
registers which are not available on all controllers.
Direct mapping for writes is not supported (yet). I have seen some
corruption with writes and I preferred to use the safer and proven
method of the initial driver [1]. We can improve that later.
The driver supports Quad SPI RX transfers on the AST2600 SoC but it
didn't have the expected results. Therefore it is not activated yet.
This needs more tests.
The series does not remove the current Aspeed SMC driver but prepares
ground for its removal by changing its CONFIG option. This last step
can be addressed as a followup when the new driver using the spi-mem
interface has been sufficiently exposed.
Tested on:
* OpenPOWER Palmetto (AST2400)
* Evaluation board (AST2500)
* OpenPOWER Witherspoon (AST2500)
* Evaluation board (AST2600 A0)
* Rainier board (AST2600)
[1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
[2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
Thanks,
C.
Cédric Le Goater (10):
mtd: spi-nor: aspeed: Rename Kconfig option
dt-bindings: spi: Add Aspeed SMC controllers device tree binding
spi: spi-mem: Add driver for Aspeed SMC controllers
spi: aspeed: Add support for direct mapping
spi: aspeed: Adjust direct mapping to device size
spi: aspeed: Workaround AST2500 limitations
spi: aspeed: Add support for the AST2400 SPI controller
spi: aspeed: Calibrate read timings
ARM: dts: aspeed: Enable Dual SPI RX transfers
spi: aspeed: Activate new spi-mem driver
drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
.../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
drivers/mtd/spi-nor/controllers/Makefile | 2 +-
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
9 files changed, 1369 insertions(+), 3 deletions(-)
create mode 100644 drivers/spi/spi-aspeed-smc.c
create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
--
2.34.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] 115+ messages in thread
* [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
To prepare transition to the new Aspeed SMC SPI controller driver using
the spi-mem interface, change the kernel CONFIG option of the current
driver to reflect that the implementation uses the MTD SPI-NOR interface.
Once the new driver is sufficiently exposed, we should remove the old one.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/configs/aspeed_g4_defconfig | 2 +-
arch/arm/configs/aspeed_g5_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/multi_v7_defconfig | 2 +-
drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
drivers/mtd/spi-nor/controllers/Makefile | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index b4a1b2ed1a17..964536444cd7 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC=y
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index ccc4240ee4b5..e809236ca88b 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC=y
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index 80a3ae02d759..49083ef05fb0 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_ORION=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC=y
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_ATMEL_SSC=m
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 33572998dbbe..fc1b69256b64 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_NAND_STM32_FMC2=y
CONFIG_MTD_NAND_PL35X=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC=m
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig b/drivers/mtd/spi-nor/controllers/Kconfig
index 5c0e0ec2e6d1..876a47042fec 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
-config SPI_ASPEED_SMC
+config SPI_ASPEED_SMC_MTD_SPI_NOR
tristate "Aspeed flash controllers in SPI mode"
depends on ARCH_ASPEED || COMPILE_TEST
depends on HAS_IOMEM && OF
diff --git a/drivers/mtd/spi-nor/controllers/Makefile b/drivers/mtd/spi-nor/controllers/Makefile
index e7abba491d98..1e28297fb1e8 100644
--- a/drivers/mtd/spi-nor/controllers/Makefile
+++ b/drivers/mtd/spi-nor/controllers/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
+obj-$(CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR) += aspeed-smc.o
obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o
obj-$(CONFIG_SPI_INTEL_SPI) += intel-spi.o
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
To prepare transition to the new Aspeed SMC SPI controller driver using
the spi-mem interface, change the kernel CONFIG option of the current
driver to reflect that the implementation uses the MTD SPI-NOR interface.
Once the new driver is sufficiently exposed, we should remove the old one.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/configs/aspeed_g4_defconfig | 2 +-
arch/arm/configs/aspeed_g5_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/multi_v7_defconfig | 2 +-
drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
drivers/mtd/spi-nor/controllers/Makefile | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index b4a1b2ed1a17..964536444cd7 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC=y
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index ccc4240ee4b5..e809236ca88b 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC=y
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index 80a3ae02d759..49083ef05fb0 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_ORION=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC=y
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_ATMEL_SSC=m
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 33572998dbbe..fc1b69256b64 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_NAND_STM32_FMC2=y
CONFIG_MTD_NAND_PL35X=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC=m
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig b/drivers/mtd/spi-nor/controllers/Kconfig
index 5c0e0ec2e6d1..876a47042fec 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
-config SPI_ASPEED_SMC
+config SPI_ASPEED_SMC_MTD_SPI_NOR
tristate "Aspeed flash controllers in SPI mode"
depends on ARCH_ASPEED || COMPILE_TEST
depends on HAS_IOMEM && OF
diff --git a/drivers/mtd/spi-nor/controllers/Makefile b/drivers/mtd/spi-nor/controllers/Makefile
index e7abba491d98..1e28297fb1e8 100644
--- a/drivers/mtd/spi-nor/controllers/Makefile
+++ b/drivers/mtd/spi-nor/controllers/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
+obj-$(CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR) += aspeed-smc.o
obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o
obj-$(CONFIG_SPI_INTEL_SPI) += intel-spi.o
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
To prepare transition to the new Aspeed SMC SPI controller driver using
the spi-mem interface, change the kernel CONFIG option of the current
driver to reflect that the implementation uses the MTD SPI-NOR interface.
Once the new driver is sufficiently exposed, we should remove the old one.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/configs/aspeed_g4_defconfig | 2 +-
arch/arm/configs/aspeed_g5_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/multi_v7_defconfig | 2 +-
drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
drivers/mtd/spi-nor/controllers/Makefile | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index b4a1b2ed1a17..964536444cd7 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC=y
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index ccc4240ee4b5..e809236ca88b 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC=y
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index 80a3ae02d759..49083ef05fb0 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_ORION=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC=y
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_ATMEL_SSC=m
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 33572998dbbe..fc1b69256b64 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_NAND_STM32_FMC2=y
CONFIG_MTD_NAND_PL35X=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC=m
+CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig b/drivers/mtd/spi-nor/controllers/Kconfig
index 5c0e0ec2e6d1..876a47042fec 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
-config SPI_ASPEED_SMC
+config SPI_ASPEED_SMC_MTD_SPI_NOR
tristate "Aspeed flash controllers in SPI mode"
depends on ARCH_ASPEED || COMPILE_TEST
depends on HAS_IOMEM && OF
diff --git a/drivers/mtd/spi-nor/controllers/Makefile b/drivers/mtd/spi-nor/controllers/Makefile
index e7abba491d98..1e28297fb1e8 100644
--- a/drivers/mtd/spi-nor/controllers/Makefile
+++ b/drivers/mtd/spi-nor/controllers/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
+obj-$(CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR) += aspeed-smc.o
obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o
obj-$(CONFIG_SPI_INTEL_SPI) += intel-spi.o
--
2.34.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] 115+ messages in thread
* [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
The "interrupt" property is optional because it is only necessary for
controllers supporting DMAs (Not implemented yet in the new driver).
Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
.../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
1 file changed, 92 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
new file mode 100644
index 000000000000..ed71c4d86930
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed SMC controllers bindings
+
+maintainers:
+ - Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
+ - Cédric Le Goater <clg@kaod.org>
+
+description: |
+ This binding describes the Aspeed Static Memory Controllers (FMC and
+ SPI) of the AST2400, AST2500 and AST2600 SOCs.
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-fmc
+ - aspeed,ast2600-spi
+ - aspeed,ast2500-fmc
+ - aspeed,ast2500-spi
+ - aspeed,ast2400-fmc
+ - aspeed,ast2400-spi
+
+ reg:
+ items:
+ - description: registers
+ - description: memory mapping
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+patternProperties:
+ "@[0-9a-f]+":
+ type: object
+
+ properties:
+ spi-rx-bus-width:
+ enum: [1, 2, 4]
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
+ #include <dt-bindings/clock/ast2600-clock.h>
+
+ spi@1e620000 {
+ reg = < 0x1e620000 0xc4
+ 0x20000000 0x10000000 >;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "aspeed,ast2600-fmc";
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ status = "disabled";
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ flash@0 {
+ reg = < 0 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+ flash@1 {
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+ flash@2 {
+ reg = < 2 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
The "interrupt" property is optional because it is only necessary for
controllers supporting DMAs (Not implemented yet in the new driver).
Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
.../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
1 file changed, 92 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
new file mode 100644
index 000000000000..ed71c4d86930
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed SMC controllers bindings
+
+maintainers:
+ - Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
+ - Cédric Le Goater <clg@kaod.org>
+
+description: |
+ This binding describes the Aspeed Static Memory Controllers (FMC and
+ SPI) of the AST2400, AST2500 and AST2600 SOCs.
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-fmc
+ - aspeed,ast2600-spi
+ - aspeed,ast2500-fmc
+ - aspeed,ast2500-spi
+ - aspeed,ast2400-fmc
+ - aspeed,ast2400-spi
+
+ reg:
+ items:
+ - description: registers
+ - description: memory mapping
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+patternProperties:
+ "@[0-9a-f]+":
+ type: object
+
+ properties:
+ spi-rx-bus-width:
+ enum: [1, 2, 4]
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
+ #include <dt-bindings/clock/ast2600-clock.h>
+
+ spi@1e620000 {
+ reg = < 0x1e620000 0xc4
+ 0x20000000 0x10000000 >;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "aspeed,ast2600-fmc";
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ status = "disabled";
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ flash@0 {
+ reg = < 0 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+ flash@1 {
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+ flash@2 {
+ reg = < 2 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+ };
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
The "interrupt" property is optional because it is only necessary for
controllers supporting DMAs (Not implemented yet in the new driver).
Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
.../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
1 file changed, 92 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
new file mode 100644
index 000000000000..ed71c4d86930
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed SMC controllers bindings
+
+maintainers:
+ - Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
+ - Cédric Le Goater <clg@kaod.org>
+
+description: |
+ This binding describes the Aspeed Static Memory Controllers (FMC and
+ SPI) of the AST2400, AST2500 and AST2600 SOCs.
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-fmc
+ - aspeed,ast2600-spi
+ - aspeed,ast2500-fmc
+ - aspeed,ast2500-spi
+ - aspeed,ast2400-fmc
+ - aspeed,ast2400-spi
+
+ reg:
+ items:
+ - description: registers
+ - description: memory mapping
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+patternProperties:
+ "@[0-9a-f]+":
+ type: object
+
+ properties:
+ spi-rx-bus-width:
+ enum: [1, 2, 4]
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
+ #include <dt-bindings/clock/ast2600-clock.h>
+
+ spi@1e620000 {
+ reg = < 0x1e620000 0xc4
+ 0x20000000 0x10000000 >;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "aspeed,ast2600-fmc";
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ status = "disabled";
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ flash@0 {
+ reg = < 0 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+ flash@1 {
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+ flash@2 {
+ reg = < 2 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+ };
--
2.34.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] 115+ messages in thread
* [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
This SPI driver adds support for the Aspeed static memory controllers
of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
* AST2600 Firmware SPI Memory Controller (FMC)
. BMC firmware
. 3 chip select pins (CE0 ~ CE2)
. Only supports SPI type flash memory
. different segment register interface
. single, dual and quad mode.
* AST2600 SPI Flash Controller (SPI1 and SPI2)
. host firmware
. 2 chip select pins (CE0 ~ CE1)
. different segment register interface
. single, dual and quad mode.
* AST2500 Firmware SPI Memory Controller (FMC)
. BMC firmware
. 3 chip select pins (CE0 ~ CE2)
. supports SPI type flash memory (CE0-CE1)
. CE2 can be of NOR type flash but this is not supported by the driver
. single, dual mode.
* AST2500 SPI Flash Controller (SPI1 and SPI2)
. host firmware
. 2 chip select pins (CE0 ~ CE1)
. single, dual mode.
* AST2400 New Static Memory Controller (also referred as FMC)
. BMC firmware
. New register set
. 5 chip select pins (CE0 ∼ CE4)
. supports NOR flash, NAND flash and SPI flash memory.
. single, dual and quad mode.
Each controller has a memory range on which flash devices contents are
mapped. Each device is assigned a window that can be changed at bootime
with the Segment Address Registers.
Each SPI flash device can then be accessed in two modes: Command and
User. When in User mode, SPI transfers are initiated with accesses to
the memory segment of a device. When in Command mode, memory
operations on the memory segment of a device generate SPI commands
automatically using a Control Register for the settings.
This initial patch adds support for User mode. Command mode needs a little
more work to check that the memory window on the AHB bus fits the device
size. It will come later when support for direct mapping is added.
Single and dual mode RX transfers are supported. Other types than SPI
are not supported.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 766 ++++++++++++++++++++++++
drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
4 files changed, 779 insertions(+), 1 deletion(-)
create mode 100644 drivers/spi/spi-aspeed-smc.c
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
new file mode 100644
index 000000000000..0aeff6f468af
--- /dev/null
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -0,0 +1,766 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * ASPEED FMC/SPI Memory Controller Driver
+ *
+ * Copyright (c) 2015-2022, IBM Corporation.
+ * Copyright (c) 2020, ASPEED Corporation.
+ */
+
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spi-mem.h>
+
+#define DEVICE_NAME "spi-aspeed-smc"
+
+#define ASPEED_SPI_DEFAULT_FREQ 50000000
+
+/* Type setting Register */
+#define CONFIG_REG 0x0
+#define CONFIG_TYPE_SPI 0x2
+
+/* CE Control Register */
+#define CE_CTRL_REG 0x4
+
+/* CEx Control Register */
+#define CE0_CTRL_REG 0x10
+#define CTRL_IO_MODE_MASK GENMASK(30, 28)
+#define CTRL_IO_SINGLE_DATA 0x0
+#define CTRL_IO_DUAL_DATA BIT(29)
+#define CTRL_IO_QUAD_DATA BIT(30)
+#define CTRL_COMMAND_SHIFT 16
+#define CTRL_IO_DUMMY_SET(dummy) \
+ (((((dummy) >> 2) & 0x1) << 14) | (((dummy) & 0x3) << 6))
+#define CTRL_CE_STOP_ACTIVE BIT(2)
+#define CTRL_IO_MODE_CMD_MASK GENMASK(1, 0)
+#define CTRL_IO_MODE_NORMAL 0x0
+#define CTRL_IO_MODE_READ 0x1
+#define CTRL_IO_MODE_WRITE 0x2
+#define CTRL_IO_MODE_USER 0x3
+
+#define CTRL_IO_CMD_MASK 0xf0ff40c3
+
+/* CEx Address Decoding Range Register */
+#define CE0_SEGMENT_ADDR_REG 0x30
+
+enum aspeed_spi_ctl_reg_value {
+ ASPEED_SPI_BASE,
+ ASPEED_SPI_READ,
+ ASPEED_SPI_WRITE,
+ ASPEED_SPI_MAX,
+};
+
+struct aspeed_spi;
+
+struct aspeed_spi_chip {
+ struct aspeed_spi *aspi;
+ u32 cs;
+ void __iomem *ctl;
+ void __iomem *ahb_base;
+ u32 ahb_window_size;
+ u32 ctl_val[ASPEED_SPI_MAX];
+ u32 clk_freq;
+};
+
+struct aspeed_spi_data {
+ u32 ctl0;
+ u32 max_cs;
+ bool hastype;
+ u32 mode_bits;
+ u32 we0;
+
+ u32 (*segment_start)(struct aspeed_spi *aspi, u32 reg);
+ u32 (*segment_end)(struct aspeed_spi *aspi, u32 reg);
+ u32 (*segment_reg)(struct aspeed_spi *aspi, u32 start, u32 end);
+};
+
+#define ASPEED_SPI_MAX_NUM_CS 5
+
+struct aspeed_spi {
+ const struct aspeed_spi_data *data;
+
+ void __iomem *regs;
+ void __iomem *ahb_base;
+ u32 ahb_base_phy;
+ u32 ahb_window_size;
+ u32 num_cs;
+ struct device *dev;
+
+ struct clk *clk;
+ u32 clk_freq;
+
+ struct aspeed_spi_chip chips[ASPEED_SPI_MAX_NUM_CS];
+};
+
+static u32 aspeed_spi_get_io_mode(const struct spi_mem_op *op)
+{
+ switch (op->data.buswidth) {
+ case 1:
+ return CTRL_IO_SINGLE_DATA;
+ case 2:
+ return CTRL_IO_DUAL_DATA;
+ case 4:
+ return CTRL_IO_QUAD_DATA;
+ default:
+ return CTRL_IO_SINGLE_DATA;
+ }
+}
+
+static void aspeed_spi_set_io_mode(struct aspeed_spi_chip *chip, u32 io_mode)
+{
+ u32 ctl;
+
+ if (io_mode > 0) {
+ ctl = readl(chip->ctl) & ~CTRL_IO_MODE_MASK;
+ ctl |= io_mode;
+ writel(ctl, chip->ctl);
+ }
+}
+
+static inline u32 aspeed_spi_chip_write_bit(struct aspeed_spi_chip *chip)
+{
+ return BIT(chip->aspi->data->we0 + chip->cs);
+}
+
+static void aspeed_spi_chip_enable(struct aspeed_spi_chip *chip, bool enable)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ u32 reg = readl(aspi->regs + CONFIG_REG);
+
+ if (enable)
+ reg |= aspeed_spi_chip_write_bit(chip);
+ else
+ reg &= ~aspeed_spi_chip_write_bit(chip);
+ writel(reg, aspi->regs + CONFIG_REG);
+}
+
+static void aspeed_spi_start_user(struct aspeed_spi_chip *chip)
+{
+ u32 ctl = chip->ctl_val[ASPEED_SPI_BASE];
+
+ ctl |= CTRL_IO_MODE_USER | CTRL_CE_STOP_ACTIVE;
+ writel(ctl, chip->ctl);
+
+ ctl &= ~CTRL_CE_STOP_ACTIVE;
+ writel(ctl, chip->ctl);
+}
+
+static void aspeed_spi_stop_user(struct aspeed_spi_chip *chip)
+{
+ u32 ctl = chip->ctl_val[ASPEED_SPI_READ] |
+ CTRL_IO_MODE_USER | CTRL_CE_STOP_ACTIVE;
+
+ writel(ctl, chip->ctl);
+
+ /* Restore defaults */
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+}
+
+static int aspeed_spi_read_from_ahb(void *buf, void __iomem *src, size_t len)
+{
+ size_t offset = 0;
+
+ if (IS_ALIGNED((uintptr_t)src, sizeof(uintptr_t)) &&
+ IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t))) {
+ ioread32_rep(src, buf, len >> 2);
+ offset = len & ~0x3;
+ len -= offset;
+ }
+ ioread8_rep(src, (u8 *)buf + offset, len);
+ return 0;
+}
+
+static int aspeed_spi_write_to_ahb(void __iomem *dst, const void *buf, size_t len)
+{
+ size_t offset = 0;
+
+ if (IS_ALIGNED((uintptr_t)dst, sizeof(uintptr_t)) &&
+ IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t))) {
+ iowrite32_rep(dst, buf, len >> 2);
+ offset = len & ~0x3;
+ len -= offset;
+ }
+ iowrite8_rep(dst, (const u8 *)buf + offset, len);
+ return 0;
+}
+
+static void aspeed_spi_send_cmd_addr(struct aspeed_spi_chip *chip, u8 addr_nbytes,
+ u64 offset, u32 opcode)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ __be32 temp;
+ u32 cmdaddr;
+
+ switch (addr_nbytes) {
+ default:
+ dev_warn_once(aspi->dev, "Unexpected address width %u, defaulting to 3",
+ addr_nbytes);
+ fallthrough;
+ case 3:
+ cmdaddr = offset & 0xFFFFFF;
+ cmdaddr |= opcode << 24;
+
+ temp = cpu_to_be32(cmdaddr);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &temp, 4);
+ break;
+ case 4:
+ temp = cpu_to_be32(offset);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &opcode, 1);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &temp, 4);
+ break;
+ }
+}
+
+static int aspeed_spi_read_reg(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op)
+{
+ aspeed_spi_start_user(chip);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &op->cmd.opcode, 1);
+ aspeed_spi_read_from_ahb(op->data.buf.in,
+ chip->ahb_base, op->data.nbytes);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+static int aspeed_spi_write_reg(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op)
+{
+ aspeed_spi_start_user(chip);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &op->cmd.opcode, 1);
+ aspeed_spi_write_to_ahb(chip->ahb_base, op->data.buf.out,
+ op->data.nbytes);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+static ssize_t aspeed_spi_read_user(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op,
+ u64 offset, size_t len, void *buf)
+{
+ int io_mode = aspeed_spi_get_io_mode(op);
+ u8 dummy = 0xFF;
+ int i;
+
+ aspeed_spi_start_user(chip);
+ aspeed_spi_send_cmd_addr(chip, op->addr.nbytes, offset, op->cmd.opcode);
+ if (op->dummy.buswidth && op->dummy.nbytes) {
+ for (i = 0; i < op->dummy.nbytes / op->dummy.buswidth; i++)
+ aspeed_spi_write_to_ahb(chip->ahb_base, &dummy, sizeof(dummy));
+ }
+
+ aspeed_spi_set_io_mode(chip, io_mode);
+
+ aspeed_spi_read_from_ahb(buf, chip->ahb_base, len);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+static ssize_t aspeed_spi_write_user(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op)
+{
+ aspeed_spi_start_user(chip);
+ aspeed_spi_send_cmd_addr(chip, op->addr.nbytes, op->addr.val, op->cmd.opcode);
+ aspeed_spi_write_to_ahb(chip->ahb_base, op->data.buf.out, op->data.nbytes);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+/* support for 1-1-1, 1-1-2 or 1-1-4 */
+static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ if (op->cmd.buswidth > 1)
+ return false;
+
+ if (op->addr.nbytes != 0) {
+ if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
+ return false;
+ }
+
+ if (op->dummy.nbytes != 0) {
+ if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
+ return false;
+ }
+
+ if (op->data.nbytes != 0 && op->data.buswidth > 4)
+ return false;
+
+ if (!spi_mem_default_supports_op(mem, op))
+ return false;
+
+ return true;
+}
+
+static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
+ struct aspeed_spi_chip *chip = &aspi->chips[mem->spi->chip_select];
+ u32 addr_mode, addr_mode_backup;
+ u32 ctl_val;
+ int ret = 0;
+
+ dev_dbg(aspi->dev,
+ "CE%d %s OP %#x mode:%d.%d.%d.%d naddr:%#x ndummies:%#x len:%#x",
+ chip->cs, op->data.dir == SPI_MEM_DATA_IN ? "read" : "write",
+ op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
+ op->dummy.buswidth, op->data.buswidth,
+ op->addr.nbytes, op->dummy.nbytes, op->data.nbytes);
+
+ addr_mode = readl(aspi->regs + CE_CTRL_REG);
+ addr_mode_backup = addr_mode;
+
+ ctl_val = chip->ctl_val[ASPEED_SPI_BASE];
+ ctl_val &= ~CTRL_IO_CMD_MASK;
+
+ ctl_val |= op->cmd.opcode << CTRL_COMMAND_SHIFT;
+
+ /* 4BYTE address mode */
+ if (op->addr.nbytes) {
+ if (op->addr.nbytes == 4)
+ addr_mode |= (0x11 << chip->cs);
+ else
+ addr_mode &= ~(0x11 << chip->cs);
+ }
+
+ if (op->dummy.buswidth && op->dummy.nbytes)
+ ctl_val |= CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth);
+
+ if (op->data.nbytes != 0) {
+ if (op->data.buswidth)
+ ctl_val |= aspeed_spi_get_io_mode(op);
+ }
+
+ if (op->data.dir == SPI_MEM_DATA_OUT)
+ ctl_val |= CTRL_IO_MODE_WRITE;
+ else
+ ctl_val |= CTRL_IO_MODE_READ;
+
+ if (addr_mode != addr_mode_backup)
+ writel(addr_mode, aspi->regs + CE_CTRL_REG);
+ writel(ctl_val, chip->ctl);
+
+ if (op->data.dir == SPI_MEM_DATA_IN) {
+ if (!op->addr.nbytes)
+ ret = aspeed_spi_read_reg(chip, op);
+ else
+ ret = aspeed_spi_read_user(chip, op, op->addr.val,
+ op->data.nbytes, op->data.buf.in);
+ } else {
+ if (!op->addr.nbytes)
+ ret = aspeed_spi_write_reg(chip, op);
+ else
+ ret = aspeed_spi_write_user(chip, op);
+ }
+
+ /* Restore defaults */
+ if (addr_mode != addr_mode_backup)
+ writel(addr_mode_backup, aspi->regs + CE_CTRL_REG);
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+ return ret;
+}
+
+static int aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ int ret;
+
+ ret = do_aspeed_spi_exec_op(mem, op);
+ if (ret)
+ dev_err(&mem->spi->dev, "operation failed: %d\n", ret);
+ return ret;
+}
+
+static const char *aspeed_spi_get_name(struct spi_mem *mem)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
+ struct device *dev = aspi->dev;
+
+ return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev), mem->spi->chip_select);
+}
+
+struct aspeed_spi_window {
+ u32 cs;
+ u32 offset;
+ u32 size;
+};
+
+static void aspeed_spi_get_windows(struct aspeed_spi *aspi,
+ struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS])
+{
+ const struct aspeed_spi_data *data = aspi->data;
+ u32 reg_val;
+ u32 cs;
+
+ for (cs = 0; cs < aspi->data->max_cs; cs++) {
+ reg_val = readl(aspi->regs + CE0_SEGMENT_ADDR_REG + cs * 4);
+ windows[cs].cs = cs;
+ windows[cs].size = data->segment_end(aspi, reg_val) -
+ data->segment_start(aspi, reg_val);
+ windows[cs].offset = cs ? windows[cs - 1].offset + windows[cs - 1].size : 0;
+ dev_vdbg(aspi->dev, "CE%d offset=0x%.8x size=0x%x\n", cs,
+ windows[cs].offset, windows[cs].size);
+ }
+}
+
+/*
+ * On the AST2600, some CE windows are closed by default at reset but
+ * U-Boot should open all.
+ */
+static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS] = { 0 };
+ struct aspeed_spi_window *win = &windows[chip->cs];
+
+ aspeed_spi_get_windows(aspi, windows);
+
+ chip->ahb_base = aspi->ahb_base + win->offset;
+ chip->ahb_window_size = win->size;
+
+ dev_dbg(aspi->dev, "CE%d default window [ 0x%.8x - 0x%.8x ] %dMB",
+ chip->cs, aspi->ahb_base_phy + win->offset,
+ aspi->ahb_base_phy + win->offset + win->size - 1,
+ win->size >> 20);
+
+ return chip->ahb_window_size ? 0 : -1;
+}
+
+static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
+ .supports_op = aspeed_spi_supports_op,
+ .exec_op = aspeed_spi_exec_op,
+ .get_name = aspeed_spi_get_name,
+};
+
+static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ u32 reg;
+
+ reg = readl(aspi->regs + CONFIG_REG);
+ reg &= ~(3 << (chip->cs * 2));
+ reg |= type << (chip->cs * 2);
+ writel(reg, aspi->regs + CONFIG_REG);
+}
+
+static int aspeed_spi_chip_init(struct aspeed_spi_chip *chip)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ const struct aspeed_spi_data *data = aspi->data;
+
+ chip->ctl = aspi->regs + data->ctl0 + chip->cs * 4;
+
+ aspeed_spi_chip_enable(chip, true);
+
+ /* The driver only supports SPI type flash */
+ if (data->hastype)
+ aspeed_spi_chip_set_type(chip, CONFIG_TYPE_SPI);
+
+ if (aspeed_spi_chip_set_default_window(chip) < 0) {
+ dev_warn(aspi->dev, "CE%d window invalid", chip->cs);
+ return -EINVAL;
+ }
+
+ chip->ctl_val[ASPEED_SPI_BASE] = CTRL_CE_STOP_ACTIVE | CTRL_IO_MODE_USER;
+ return 0;
+}
+
+static int aspeed_spi_init_devices(struct platform_device *pdev, struct aspeed_spi *aspi)
+{
+ struct device_node *np;
+ unsigned int cs;
+ int ret;
+
+ for_each_available_child_of_node(aspi->dev->of_node, np) {
+ struct aspeed_spi_chip *chip;
+
+ if (!of_device_is_compatible(np, "jedec,spi-nor"))
+ continue;
+
+ ret = of_property_read_u32(np, "reg", &cs);
+ if (ret) {
+ dev_err(aspi->dev, "Couldn't not read chip select.\n");
+ of_node_put(np);
+ return ret;
+ }
+
+ if (cs > aspi->data->max_cs) {
+ dev_err(aspi->dev, "Chip select %d out of range.\n", cs);
+ of_node_put(np);
+ return -ERANGE;
+ }
+
+ chip = &aspi->chips[cs];
+ chip->aspi = aspi;
+ chip->cs = cs;
+
+ ret = aspeed_spi_chip_init(chip);
+ if (ret) {
+ of_node_put(np);
+ return ret;
+ }
+
+ if (of_property_read_u32(np, "spi-max-frequency", &chip->clk_freq))
+ chip->clk_freq = ASPEED_SPI_DEFAULT_FREQ;
+
+ aspi->num_cs++;
+ }
+
+ return 0;
+}
+
+static void aspeed_spi_enable(struct aspeed_spi *aspi, bool enable)
+{
+ int cs;
+
+ for (cs = 0; cs < aspi->num_cs; cs++)
+ aspeed_spi_chip_enable(&aspi->chips[cs], enable);
+}
+
+static int aspeed_spi_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct aspeed_spi_data *data;
+ struct spi_controller *ctlr;
+ struct aspeed_spi *aspi;
+ struct resource *res;
+ int ret;
+
+ data = of_device_get_match_data(&pdev->dev);
+ if (!data)
+ return -ENODEV;
+
+ ctlr = spi_alloc_master(dev, sizeof(*aspi));
+ if (!ctlr)
+ return -ENOMEM;
+
+ aspi = spi_controller_get_devdata(ctlr);
+ platform_set_drvdata(pdev, aspi);
+ aspi->data = data;
+ aspi->dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ aspi->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(aspi->regs)) {
+ ret = PTR_ERR(aspi->regs);
+ goto put_controller;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ aspi->ahb_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(aspi->ahb_base)) {
+ ret = PTR_ERR(aspi->ahb_base);
+ goto put_controller;
+ }
+
+ aspi->ahb_window_size = resource_size(res);
+ aspi->ahb_base_phy = res->start;
+
+ aspi->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(aspi->clk)) {
+ ret = PTR_ERR(aspi->clk);
+ goto put_controller;
+ }
+
+ aspi->clk_freq = clk_get_rate(aspi->clk);
+ if (!aspi->clk_freq) {
+ ret = -EINVAL;
+ goto put_controller;
+ }
+
+ ret = clk_prepare_enable(aspi->clk);
+ if (ret) {
+ dev_err(dev, "can not enable the clock\n");
+ goto put_controller;
+ }
+
+ ret = aspeed_spi_init_devices(pdev, aspi);
+ if (ret)
+ goto disable_clk;
+
+ if (!aspi->num_cs) {
+ dev_err(&pdev->dev, "no devices ?!\n");
+ ret = -ENODEV;
+ goto disable_clk;
+ }
+
+ /* IRQ is for DMA, which the driver doesn't support yet */
+
+ ctlr->mode_bits = SPI_RX_DUAL | SPI_TX_DUAL | aspi->data->mode_bits;
+ ctlr->bus_num = pdev->id;
+ ctlr->mem_ops = &aspeed_spi_mem_ops;
+ ctlr->num_chipselect = aspi->num_cs;
+ ctlr->dev.of_node = dev->of_node;
+
+ ret = devm_spi_register_controller(dev, ctlr);
+ if (ret) {
+ dev_err(&pdev->dev, "spi_register_controller failed\n");
+ goto disable_aspi;
+ }
+
+ dev_dbg(&pdev->dev, "probed %d devices\n", aspi->num_cs);
+ return 0;
+
+disable_aspi:
+ aspeed_spi_enable(aspi, false);
+disable_clk:
+ clk_disable_unprepare(aspi->clk);
+put_controller:
+ spi_controller_put(ctlr);
+
+ return ret;
+}
+
+static int aspeed_spi_remove(struct platform_device *pdev)
+{
+ struct spi_controller *ctlr = platform_get_drvdata(pdev);
+ struct aspeed_spi *aspi = spi_controller_get_devdata(ctlr);
+
+ aspeed_spi_enable(aspi, false);
+ spi_unregister_controller(ctlr);
+ clk_disable_unprepare(aspi->clk);
+ return 0;
+}
+
+/*
+ * AHB mappings
+ */
+
+/*
+ * The Segment Registers of the AST2400 and AST2500 use a 8MB unit.
+ * The address range is encoded with absolute addresses in the overall
+ * mapping window.
+ */
+static u32 aspeed_spi_segment_start(struct aspeed_spi *aspi, u32 reg)
+{
+ return ((reg >> 16) & 0xFF) << 23;
+}
+
+static u32 aspeed_spi_segment_end(struct aspeed_spi *aspi, u32 reg)
+{
+ return ((reg >> 24) & 0xFF) << 23;
+}
+
+static u32 aspeed_spi_segment_reg(struct aspeed_spi *aspi, u32 start, u32 end)
+{
+ return (((start >> 23) & 0xFF) << 16) | (((end >> 23) & 0xFF) << 24);
+}
+
+/*
+ * The Segment Registers of the AST2600 use a 1MB unit. The address
+ * range is encoded with offsets in the overall mapping window.
+ */
+
+#define AST2600_SEG_ADDR_MASK 0x0ff00000
+
+static u32 aspeed_spi_segment_ast2600_start(struct aspeed_spi *aspi,
+ u32 reg)
+{
+ u32 start_offset = (reg << 16) & AST2600_SEG_ADDR_MASK;
+
+ return aspi->ahb_base_phy + start_offset;
+}
+
+static u32 aspeed_spi_segment_ast2600_end(struct aspeed_spi *aspi,
+ u32 reg)
+{
+ u32 end_offset = reg & AST2600_SEG_ADDR_MASK;
+
+ /* segment is disabled */
+ if (!end_offset)
+ return aspi->ahb_base_phy;
+
+ return aspi->ahb_base_phy + end_offset + 0x100000;
+}
+
+static u32 aspeed_spi_segment_ast2600_reg(struct aspeed_spi *aspi,
+ u32 start, u32 end)
+{
+ /* disable zero size segments */
+ if (start == end)
+ return 0;
+
+ return ((start & AST2600_SEG_ADDR_MASK) >> 16) |
+ ((end - 1) & AST2600_SEG_ADDR_MASK);
+}
+
+/*
+ * Platform definitions
+ */
+static const struct aspeed_spi_data ast2400_fmc_data = {
+ .max_cs = 5,
+ .hastype = true,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_start,
+ .segment_end = aspeed_spi_segment_end,
+ .segment_reg = aspeed_spi_segment_reg,
+};
+
+static const struct aspeed_spi_data ast2500_fmc_data = {
+ .max_cs = 3,
+ .hastype = true,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_start,
+ .segment_end = aspeed_spi_segment_end,
+ .segment_reg = aspeed_spi_segment_reg,
+};
+
+static const struct aspeed_spi_data ast2500_spi_data = {
+ .max_cs = 2,
+ .hastype = false,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_start,
+ .segment_end = aspeed_spi_segment_end,
+ .segment_reg = aspeed_spi_segment_reg,
+};
+
+static const struct aspeed_spi_data ast2600_fmc_data = {
+ .max_cs = 3,
+ .hastype = false,
+ .mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_ast2600_start,
+ .segment_end = aspeed_spi_segment_ast2600_end,
+ .segment_reg = aspeed_spi_segment_ast2600_reg,
+};
+
+static const struct aspeed_spi_data ast2600_spi_data = {
+ .max_cs = 2,
+ .hastype = false,
+ .mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_ast2600_start,
+ .segment_end = aspeed_spi_segment_ast2600_end,
+ .segment_reg = aspeed_spi_segment_ast2600_reg,
+};
+
+static const struct of_device_id aspeed_spi_matches[] = {
+ { .compatible = "aspeed,ast2400-fmc", .data = &ast2400_fmc_data },
+ { .compatible = "aspeed,ast2500-fmc", .data = &ast2500_fmc_data },
+ { .compatible = "aspeed,ast2500-spi", .data = &ast2500_spi_data },
+ { .compatible = "aspeed,ast2600-fmc", .data = &ast2600_fmc_data },
+ { .compatible = "aspeed,ast2600-spi", .data = &ast2600_spi_data },
+ { }
+};
+MODULE_DEVICE_TABLE(of, aspeed_spi_matches);
+
+static struct platform_driver aspeed_spi_driver = {
+ .probe = aspeed_spi_probe,
+ .remove = aspeed_spi_remove,
+ .driver = {
+ .name = DEVICE_NAME,
+ .of_match_table = aspeed_spi_matches,
+ }
+};
+
+module_platform_driver(aspeed_spi_driver);
+
+MODULE_DESCRIPTION("ASPEED Static Memory Controller Driver");
+MODULE_AUTHOR("Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>");
+MODULE_AUTHOR("Cedric Le Goater <clg@kaod.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig b/drivers/mtd/spi-nor/controllers/Kconfig
index 876a47042fec..35f18c01b1d8 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config SPI_ASPEED_SMC_MTD_SPI_NOR
tristate "Aspeed flash controllers in SPI mode"
- depends on ARCH_ASPEED || COMPILE_TEST
+ depends on (ARCH_ASPEED && !SPI_ASPEED_SMC) || COMPILE_TEST
depends on HAS_IOMEM && OF
help
This enables support for the Firmware Memory controller (FMC)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 83e352b0c8f9..dc44493439fb 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -101,6 +101,17 @@ config SPI_ARMADA_3700
This enables support for the SPI controller present on the
Marvell Armada 3700 SoCs.
+config SPI_ASPEED_SMC
+ tristate "Aspeed flash controllers in SPI mode"
+ depends on (ARCH_ASPEED && !CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR) || COMPILE_TEST
+ depends on OF
+ help
+ This enables support for the Firmware Memory controller (FMC)
+ in the Aspeed AST2600, AST2500 and AST2400 SoCs when attached
+ to SPI NOR chips, and support for the SPI flash memory
+ controller (SPI) for the host firmware. The implementation
+ only supports SPI NOR.
+
config SPI_ATMEL
tristate "Atmel SPI Controller"
depends on ARCH_AT91 || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 699db95c8441..3dd0e649be94 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SPI_ALTERA_CORE) += spi-altera-core.o
obj-$(CONFIG_SPI_ALTERA_DFL) += spi-altera-dfl.o
obj-$(CONFIG_SPI_AR934X) += spi-ar934x.o
obj-$(CONFIG_SPI_ARMADA_3700) += spi-armada-3700.o
+obj-$(CONFIG_SPI_ASPEED_SMC) += spi-aspeed-smc.o
obj-$(CONFIG_SPI_ATMEL) += spi-atmel.o
obj-$(CONFIG_SPI_ATMEL_QUADSPI) += atmel-quadspi.o
obj-$(CONFIG_SPI_AT91_USART) += spi-at91-usart.o
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
This SPI driver adds support for the Aspeed static memory controllers
of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
* AST2600 Firmware SPI Memory Controller (FMC)
. BMC firmware
. 3 chip select pins (CE0 ~ CE2)
. Only supports SPI type flash memory
. different segment register interface
. single, dual and quad mode.
* AST2600 SPI Flash Controller (SPI1 and SPI2)
. host firmware
. 2 chip select pins (CE0 ~ CE1)
. different segment register interface
. single, dual and quad mode.
* AST2500 Firmware SPI Memory Controller (FMC)
. BMC firmware
. 3 chip select pins (CE0 ~ CE2)
. supports SPI type flash memory (CE0-CE1)
. CE2 can be of NOR type flash but this is not supported by the driver
. single, dual mode.
* AST2500 SPI Flash Controller (SPI1 and SPI2)
. host firmware
. 2 chip select pins (CE0 ~ CE1)
. single, dual mode.
* AST2400 New Static Memory Controller (also referred as FMC)
. BMC firmware
. New register set
. 5 chip select pins (CE0 ∼ CE4)
. supports NOR flash, NAND flash and SPI flash memory.
. single, dual and quad mode.
Each controller has a memory range on which flash devices contents are
mapped. Each device is assigned a window that can be changed at bootime
with the Segment Address Registers.
Each SPI flash device can then be accessed in two modes: Command and
User. When in User mode, SPI transfers are initiated with accesses to
the memory segment of a device. When in Command mode, memory
operations on the memory segment of a device generate SPI commands
automatically using a Control Register for the settings.
This initial patch adds support for User mode. Command mode needs a little
more work to check that the memory window on the AHB bus fits the device
size. It will come later when support for direct mapping is added.
Single and dual mode RX transfers are supported. Other types than SPI
are not supported.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 766 ++++++++++++++++++++++++
drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
4 files changed, 779 insertions(+), 1 deletion(-)
create mode 100644 drivers/spi/spi-aspeed-smc.c
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
new file mode 100644
index 000000000000..0aeff6f468af
--- /dev/null
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -0,0 +1,766 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * ASPEED FMC/SPI Memory Controller Driver
+ *
+ * Copyright (c) 2015-2022, IBM Corporation.
+ * Copyright (c) 2020, ASPEED Corporation.
+ */
+
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spi-mem.h>
+
+#define DEVICE_NAME "spi-aspeed-smc"
+
+#define ASPEED_SPI_DEFAULT_FREQ 50000000
+
+/* Type setting Register */
+#define CONFIG_REG 0x0
+#define CONFIG_TYPE_SPI 0x2
+
+/* CE Control Register */
+#define CE_CTRL_REG 0x4
+
+/* CEx Control Register */
+#define CE0_CTRL_REG 0x10
+#define CTRL_IO_MODE_MASK GENMASK(30, 28)
+#define CTRL_IO_SINGLE_DATA 0x0
+#define CTRL_IO_DUAL_DATA BIT(29)
+#define CTRL_IO_QUAD_DATA BIT(30)
+#define CTRL_COMMAND_SHIFT 16
+#define CTRL_IO_DUMMY_SET(dummy) \
+ (((((dummy) >> 2) & 0x1) << 14) | (((dummy) & 0x3) << 6))
+#define CTRL_CE_STOP_ACTIVE BIT(2)
+#define CTRL_IO_MODE_CMD_MASK GENMASK(1, 0)
+#define CTRL_IO_MODE_NORMAL 0x0
+#define CTRL_IO_MODE_READ 0x1
+#define CTRL_IO_MODE_WRITE 0x2
+#define CTRL_IO_MODE_USER 0x3
+
+#define CTRL_IO_CMD_MASK 0xf0ff40c3
+
+/* CEx Address Decoding Range Register */
+#define CE0_SEGMENT_ADDR_REG 0x30
+
+enum aspeed_spi_ctl_reg_value {
+ ASPEED_SPI_BASE,
+ ASPEED_SPI_READ,
+ ASPEED_SPI_WRITE,
+ ASPEED_SPI_MAX,
+};
+
+struct aspeed_spi;
+
+struct aspeed_spi_chip {
+ struct aspeed_spi *aspi;
+ u32 cs;
+ void __iomem *ctl;
+ void __iomem *ahb_base;
+ u32 ahb_window_size;
+ u32 ctl_val[ASPEED_SPI_MAX];
+ u32 clk_freq;
+};
+
+struct aspeed_spi_data {
+ u32 ctl0;
+ u32 max_cs;
+ bool hastype;
+ u32 mode_bits;
+ u32 we0;
+
+ u32 (*segment_start)(struct aspeed_spi *aspi, u32 reg);
+ u32 (*segment_end)(struct aspeed_spi *aspi, u32 reg);
+ u32 (*segment_reg)(struct aspeed_spi *aspi, u32 start, u32 end);
+};
+
+#define ASPEED_SPI_MAX_NUM_CS 5
+
+struct aspeed_spi {
+ const struct aspeed_spi_data *data;
+
+ void __iomem *regs;
+ void __iomem *ahb_base;
+ u32 ahb_base_phy;
+ u32 ahb_window_size;
+ u32 num_cs;
+ struct device *dev;
+
+ struct clk *clk;
+ u32 clk_freq;
+
+ struct aspeed_spi_chip chips[ASPEED_SPI_MAX_NUM_CS];
+};
+
+static u32 aspeed_spi_get_io_mode(const struct spi_mem_op *op)
+{
+ switch (op->data.buswidth) {
+ case 1:
+ return CTRL_IO_SINGLE_DATA;
+ case 2:
+ return CTRL_IO_DUAL_DATA;
+ case 4:
+ return CTRL_IO_QUAD_DATA;
+ default:
+ return CTRL_IO_SINGLE_DATA;
+ }
+}
+
+static void aspeed_spi_set_io_mode(struct aspeed_spi_chip *chip, u32 io_mode)
+{
+ u32 ctl;
+
+ if (io_mode > 0) {
+ ctl = readl(chip->ctl) & ~CTRL_IO_MODE_MASK;
+ ctl |= io_mode;
+ writel(ctl, chip->ctl);
+ }
+}
+
+static inline u32 aspeed_spi_chip_write_bit(struct aspeed_spi_chip *chip)
+{
+ return BIT(chip->aspi->data->we0 + chip->cs);
+}
+
+static void aspeed_spi_chip_enable(struct aspeed_spi_chip *chip, bool enable)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ u32 reg = readl(aspi->regs + CONFIG_REG);
+
+ if (enable)
+ reg |= aspeed_spi_chip_write_bit(chip);
+ else
+ reg &= ~aspeed_spi_chip_write_bit(chip);
+ writel(reg, aspi->regs + CONFIG_REG);
+}
+
+static void aspeed_spi_start_user(struct aspeed_spi_chip *chip)
+{
+ u32 ctl = chip->ctl_val[ASPEED_SPI_BASE];
+
+ ctl |= CTRL_IO_MODE_USER | CTRL_CE_STOP_ACTIVE;
+ writel(ctl, chip->ctl);
+
+ ctl &= ~CTRL_CE_STOP_ACTIVE;
+ writel(ctl, chip->ctl);
+}
+
+static void aspeed_spi_stop_user(struct aspeed_spi_chip *chip)
+{
+ u32 ctl = chip->ctl_val[ASPEED_SPI_READ] |
+ CTRL_IO_MODE_USER | CTRL_CE_STOP_ACTIVE;
+
+ writel(ctl, chip->ctl);
+
+ /* Restore defaults */
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+}
+
+static int aspeed_spi_read_from_ahb(void *buf, void __iomem *src, size_t len)
+{
+ size_t offset = 0;
+
+ if (IS_ALIGNED((uintptr_t)src, sizeof(uintptr_t)) &&
+ IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t))) {
+ ioread32_rep(src, buf, len >> 2);
+ offset = len & ~0x3;
+ len -= offset;
+ }
+ ioread8_rep(src, (u8 *)buf + offset, len);
+ return 0;
+}
+
+static int aspeed_spi_write_to_ahb(void __iomem *dst, const void *buf, size_t len)
+{
+ size_t offset = 0;
+
+ if (IS_ALIGNED((uintptr_t)dst, sizeof(uintptr_t)) &&
+ IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t))) {
+ iowrite32_rep(dst, buf, len >> 2);
+ offset = len & ~0x3;
+ len -= offset;
+ }
+ iowrite8_rep(dst, (const u8 *)buf + offset, len);
+ return 0;
+}
+
+static void aspeed_spi_send_cmd_addr(struct aspeed_spi_chip *chip, u8 addr_nbytes,
+ u64 offset, u32 opcode)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ __be32 temp;
+ u32 cmdaddr;
+
+ switch (addr_nbytes) {
+ default:
+ dev_warn_once(aspi->dev, "Unexpected address width %u, defaulting to 3",
+ addr_nbytes);
+ fallthrough;
+ case 3:
+ cmdaddr = offset & 0xFFFFFF;
+ cmdaddr |= opcode << 24;
+
+ temp = cpu_to_be32(cmdaddr);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &temp, 4);
+ break;
+ case 4:
+ temp = cpu_to_be32(offset);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &opcode, 1);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &temp, 4);
+ break;
+ }
+}
+
+static int aspeed_spi_read_reg(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op)
+{
+ aspeed_spi_start_user(chip);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &op->cmd.opcode, 1);
+ aspeed_spi_read_from_ahb(op->data.buf.in,
+ chip->ahb_base, op->data.nbytes);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+static int aspeed_spi_write_reg(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op)
+{
+ aspeed_spi_start_user(chip);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &op->cmd.opcode, 1);
+ aspeed_spi_write_to_ahb(chip->ahb_base, op->data.buf.out,
+ op->data.nbytes);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+static ssize_t aspeed_spi_read_user(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op,
+ u64 offset, size_t len, void *buf)
+{
+ int io_mode = aspeed_spi_get_io_mode(op);
+ u8 dummy = 0xFF;
+ int i;
+
+ aspeed_spi_start_user(chip);
+ aspeed_spi_send_cmd_addr(chip, op->addr.nbytes, offset, op->cmd.opcode);
+ if (op->dummy.buswidth && op->dummy.nbytes) {
+ for (i = 0; i < op->dummy.nbytes / op->dummy.buswidth; i++)
+ aspeed_spi_write_to_ahb(chip->ahb_base, &dummy, sizeof(dummy));
+ }
+
+ aspeed_spi_set_io_mode(chip, io_mode);
+
+ aspeed_spi_read_from_ahb(buf, chip->ahb_base, len);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+static ssize_t aspeed_spi_write_user(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op)
+{
+ aspeed_spi_start_user(chip);
+ aspeed_spi_send_cmd_addr(chip, op->addr.nbytes, op->addr.val, op->cmd.opcode);
+ aspeed_spi_write_to_ahb(chip->ahb_base, op->data.buf.out, op->data.nbytes);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+/* support for 1-1-1, 1-1-2 or 1-1-4 */
+static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ if (op->cmd.buswidth > 1)
+ return false;
+
+ if (op->addr.nbytes != 0) {
+ if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
+ return false;
+ }
+
+ if (op->dummy.nbytes != 0) {
+ if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
+ return false;
+ }
+
+ if (op->data.nbytes != 0 && op->data.buswidth > 4)
+ return false;
+
+ if (!spi_mem_default_supports_op(mem, op))
+ return false;
+
+ return true;
+}
+
+static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
+ struct aspeed_spi_chip *chip = &aspi->chips[mem->spi->chip_select];
+ u32 addr_mode, addr_mode_backup;
+ u32 ctl_val;
+ int ret = 0;
+
+ dev_dbg(aspi->dev,
+ "CE%d %s OP %#x mode:%d.%d.%d.%d naddr:%#x ndummies:%#x len:%#x",
+ chip->cs, op->data.dir == SPI_MEM_DATA_IN ? "read" : "write",
+ op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
+ op->dummy.buswidth, op->data.buswidth,
+ op->addr.nbytes, op->dummy.nbytes, op->data.nbytes);
+
+ addr_mode = readl(aspi->regs + CE_CTRL_REG);
+ addr_mode_backup = addr_mode;
+
+ ctl_val = chip->ctl_val[ASPEED_SPI_BASE];
+ ctl_val &= ~CTRL_IO_CMD_MASK;
+
+ ctl_val |= op->cmd.opcode << CTRL_COMMAND_SHIFT;
+
+ /* 4BYTE address mode */
+ if (op->addr.nbytes) {
+ if (op->addr.nbytes == 4)
+ addr_mode |= (0x11 << chip->cs);
+ else
+ addr_mode &= ~(0x11 << chip->cs);
+ }
+
+ if (op->dummy.buswidth && op->dummy.nbytes)
+ ctl_val |= CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth);
+
+ if (op->data.nbytes != 0) {
+ if (op->data.buswidth)
+ ctl_val |= aspeed_spi_get_io_mode(op);
+ }
+
+ if (op->data.dir == SPI_MEM_DATA_OUT)
+ ctl_val |= CTRL_IO_MODE_WRITE;
+ else
+ ctl_val |= CTRL_IO_MODE_READ;
+
+ if (addr_mode != addr_mode_backup)
+ writel(addr_mode, aspi->regs + CE_CTRL_REG);
+ writel(ctl_val, chip->ctl);
+
+ if (op->data.dir == SPI_MEM_DATA_IN) {
+ if (!op->addr.nbytes)
+ ret = aspeed_spi_read_reg(chip, op);
+ else
+ ret = aspeed_spi_read_user(chip, op, op->addr.val,
+ op->data.nbytes, op->data.buf.in);
+ } else {
+ if (!op->addr.nbytes)
+ ret = aspeed_spi_write_reg(chip, op);
+ else
+ ret = aspeed_spi_write_user(chip, op);
+ }
+
+ /* Restore defaults */
+ if (addr_mode != addr_mode_backup)
+ writel(addr_mode_backup, aspi->regs + CE_CTRL_REG);
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+ return ret;
+}
+
+static int aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ int ret;
+
+ ret = do_aspeed_spi_exec_op(mem, op);
+ if (ret)
+ dev_err(&mem->spi->dev, "operation failed: %d\n", ret);
+ return ret;
+}
+
+static const char *aspeed_spi_get_name(struct spi_mem *mem)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
+ struct device *dev = aspi->dev;
+
+ return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev), mem->spi->chip_select);
+}
+
+struct aspeed_spi_window {
+ u32 cs;
+ u32 offset;
+ u32 size;
+};
+
+static void aspeed_spi_get_windows(struct aspeed_spi *aspi,
+ struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS])
+{
+ const struct aspeed_spi_data *data = aspi->data;
+ u32 reg_val;
+ u32 cs;
+
+ for (cs = 0; cs < aspi->data->max_cs; cs++) {
+ reg_val = readl(aspi->regs + CE0_SEGMENT_ADDR_REG + cs * 4);
+ windows[cs].cs = cs;
+ windows[cs].size = data->segment_end(aspi, reg_val) -
+ data->segment_start(aspi, reg_val);
+ windows[cs].offset = cs ? windows[cs - 1].offset + windows[cs - 1].size : 0;
+ dev_vdbg(aspi->dev, "CE%d offset=0x%.8x size=0x%x\n", cs,
+ windows[cs].offset, windows[cs].size);
+ }
+}
+
+/*
+ * On the AST2600, some CE windows are closed by default at reset but
+ * U-Boot should open all.
+ */
+static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS] = { 0 };
+ struct aspeed_spi_window *win = &windows[chip->cs];
+
+ aspeed_spi_get_windows(aspi, windows);
+
+ chip->ahb_base = aspi->ahb_base + win->offset;
+ chip->ahb_window_size = win->size;
+
+ dev_dbg(aspi->dev, "CE%d default window [ 0x%.8x - 0x%.8x ] %dMB",
+ chip->cs, aspi->ahb_base_phy + win->offset,
+ aspi->ahb_base_phy + win->offset + win->size - 1,
+ win->size >> 20);
+
+ return chip->ahb_window_size ? 0 : -1;
+}
+
+static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
+ .supports_op = aspeed_spi_supports_op,
+ .exec_op = aspeed_spi_exec_op,
+ .get_name = aspeed_spi_get_name,
+};
+
+static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ u32 reg;
+
+ reg = readl(aspi->regs + CONFIG_REG);
+ reg &= ~(3 << (chip->cs * 2));
+ reg |= type << (chip->cs * 2);
+ writel(reg, aspi->regs + CONFIG_REG);
+}
+
+static int aspeed_spi_chip_init(struct aspeed_spi_chip *chip)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ const struct aspeed_spi_data *data = aspi->data;
+
+ chip->ctl = aspi->regs + data->ctl0 + chip->cs * 4;
+
+ aspeed_spi_chip_enable(chip, true);
+
+ /* The driver only supports SPI type flash */
+ if (data->hastype)
+ aspeed_spi_chip_set_type(chip, CONFIG_TYPE_SPI);
+
+ if (aspeed_spi_chip_set_default_window(chip) < 0) {
+ dev_warn(aspi->dev, "CE%d window invalid", chip->cs);
+ return -EINVAL;
+ }
+
+ chip->ctl_val[ASPEED_SPI_BASE] = CTRL_CE_STOP_ACTIVE | CTRL_IO_MODE_USER;
+ return 0;
+}
+
+static int aspeed_spi_init_devices(struct platform_device *pdev, struct aspeed_spi *aspi)
+{
+ struct device_node *np;
+ unsigned int cs;
+ int ret;
+
+ for_each_available_child_of_node(aspi->dev->of_node, np) {
+ struct aspeed_spi_chip *chip;
+
+ if (!of_device_is_compatible(np, "jedec,spi-nor"))
+ continue;
+
+ ret = of_property_read_u32(np, "reg", &cs);
+ if (ret) {
+ dev_err(aspi->dev, "Couldn't not read chip select.\n");
+ of_node_put(np);
+ return ret;
+ }
+
+ if (cs > aspi->data->max_cs) {
+ dev_err(aspi->dev, "Chip select %d out of range.\n", cs);
+ of_node_put(np);
+ return -ERANGE;
+ }
+
+ chip = &aspi->chips[cs];
+ chip->aspi = aspi;
+ chip->cs = cs;
+
+ ret = aspeed_spi_chip_init(chip);
+ if (ret) {
+ of_node_put(np);
+ return ret;
+ }
+
+ if (of_property_read_u32(np, "spi-max-frequency", &chip->clk_freq))
+ chip->clk_freq = ASPEED_SPI_DEFAULT_FREQ;
+
+ aspi->num_cs++;
+ }
+
+ return 0;
+}
+
+static void aspeed_spi_enable(struct aspeed_spi *aspi, bool enable)
+{
+ int cs;
+
+ for (cs = 0; cs < aspi->num_cs; cs++)
+ aspeed_spi_chip_enable(&aspi->chips[cs], enable);
+}
+
+static int aspeed_spi_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct aspeed_spi_data *data;
+ struct spi_controller *ctlr;
+ struct aspeed_spi *aspi;
+ struct resource *res;
+ int ret;
+
+ data = of_device_get_match_data(&pdev->dev);
+ if (!data)
+ return -ENODEV;
+
+ ctlr = spi_alloc_master(dev, sizeof(*aspi));
+ if (!ctlr)
+ return -ENOMEM;
+
+ aspi = spi_controller_get_devdata(ctlr);
+ platform_set_drvdata(pdev, aspi);
+ aspi->data = data;
+ aspi->dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ aspi->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(aspi->regs)) {
+ ret = PTR_ERR(aspi->regs);
+ goto put_controller;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ aspi->ahb_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(aspi->ahb_base)) {
+ ret = PTR_ERR(aspi->ahb_base);
+ goto put_controller;
+ }
+
+ aspi->ahb_window_size = resource_size(res);
+ aspi->ahb_base_phy = res->start;
+
+ aspi->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(aspi->clk)) {
+ ret = PTR_ERR(aspi->clk);
+ goto put_controller;
+ }
+
+ aspi->clk_freq = clk_get_rate(aspi->clk);
+ if (!aspi->clk_freq) {
+ ret = -EINVAL;
+ goto put_controller;
+ }
+
+ ret = clk_prepare_enable(aspi->clk);
+ if (ret) {
+ dev_err(dev, "can not enable the clock\n");
+ goto put_controller;
+ }
+
+ ret = aspeed_spi_init_devices(pdev, aspi);
+ if (ret)
+ goto disable_clk;
+
+ if (!aspi->num_cs) {
+ dev_err(&pdev->dev, "no devices ?!\n");
+ ret = -ENODEV;
+ goto disable_clk;
+ }
+
+ /* IRQ is for DMA, which the driver doesn't support yet */
+
+ ctlr->mode_bits = SPI_RX_DUAL | SPI_TX_DUAL | aspi->data->mode_bits;
+ ctlr->bus_num = pdev->id;
+ ctlr->mem_ops = &aspeed_spi_mem_ops;
+ ctlr->num_chipselect = aspi->num_cs;
+ ctlr->dev.of_node = dev->of_node;
+
+ ret = devm_spi_register_controller(dev, ctlr);
+ if (ret) {
+ dev_err(&pdev->dev, "spi_register_controller failed\n");
+ goto disable_aspi;
+ }
+
+ dev_dbg(&pdev->dev, "probed %d devices\n", aspi->num_cs);
+ return 0;
+
+disable_aspi:
+ aspeed_spi_enable(aspi, false);
+disable_clk:
+ clk_disable_unprepare(aspi->clk);
+put_controller:
+ spi_controller_put(ctlr);
+
+ return ret;
+}
+
+static int aspeed_spi_remove(struct platform_device *pdev)
+{
+ struct spi_controller *ctlr = platform_get_drvdata(pdev);
+ struct aspeed_spi *aspi = spi_controller_get_devdata(ctlr);
+
+ aspeed_spi_enable(aspi, false);
+ spi_unregister_controller(ctlr);
+ clk_disable_unprepare(aspi->clk);
+ return 0;
+}
+
+/*
+ * AHB mappings
+ */
+
+/*
+ * The Segment Registers of the AST2400 and AST2500 use a 8MB unit.
+ * The address range is encoded with absolute addresses in the overall
+ * mapping window.
+ */
+static u32 aspeed_spi_segment_start(struct aspeed_spi *aspi, u32 reg)
+{
+ return ((reg >> 16) & 0xFF) << 23;
+}
+
+static u32 aspeed_spi_segment_end(struct aspeed_spi *aspi, u32 reg)
+{
+ return ((reg >> 24) & 0xFF) << 23;
+}
+
+static u32 aspeed_spi_segment_reg(struct aspeed_spi *aspi, u32 start, u32 end)
+{
+ return (((start >> 23) & 0xFF) << 16) | (((end >> 23) & 0xFF) << 24);
+}
+
+/*
+ * The Segment Registers of the AST2600 use a 1MB unit. The address
+ * range is encoded with offsets in the overall mapping window.
+ */
+
+#define AST2600_SEG_ADDR_MASK 0x0ff00000
+
+static u32 aspeed_spi_segment_ast2600_start(struct aspeed_spi *aspi,
+ u32 reg)
+{
+ u32 start_offset = (reg << 16) & AST2600_SEG_ADDR_MASK;
+
+ return aspi->ahb_base_phy + start_offset;
+}
+
+static u32 aspeed_spi_segment_ast2600_end(struct aspeed_spi *aspi,
+ u32 reg)
+{
+ u32 end_offset = reg & AST2600_SEG_ADDR_MASK;
+
+ /* segment is disabled */
+ if (!end_offset)
+ return aspi->ahb_base_phy;
+
+ return aspi->ahb_base_phy + end_offset + 0x100000;
+}
+
+static u32 aspeed_spi_segment_ast2600_reg(struct aspeed_spi *aspi,
+ u32 start, u32 end)
+{
+ /* disable zero size segments */
+ if (start == end)
+ return 0;
+
+ return ((start & AST2600_SEG_ADDR_MASK) >> 16) |
+ ((end - 1) & AST2600_SEG_ADDR_MASK);
+}
+
+/*
+ * Platform definitions
+ */
+static const struct aspeed_spi_data ast2400_fmc_data = {
+ .max_cs = 5,
+ .hastype = true,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_start,
+ .segment_end = aspeed_spi_segment_end,
+ .segment_reg = aspeed_spi_segment_reg,
+};
+
+static const struct aspeed_spi_data ast2500_fmc_data = {
+ .max_cs = 3,
+ .hastype = true,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_start,
+ .segment_end = aspeed_spi_segment_end,
+ .segment_reg = aspeed_spi_segment_reg,
+};
+
+static const struct aspeed_spi_data ast2500_spi_data = {
+ .max_cs = 2,
+ .hastype = false,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_start,
+ .segment_end = aspeed_spi_segment_end,
+ .segment_reg = aspeed_spi_segment_reg,
+};
+
+static const struct aspeed_spi_data ast2600_fmc_data = {
+ .max_cs = 3,
+ .hastype = false,
+ .mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_ast2600_start,
+ .segment_end = aspeed_spi_segment_ast2600_end,
+ .segment_reg = aspeed_spi_segment_ast2600_reg,
+};
+
+static const struct aspeed_spi_data ast2600_spi_data = {
+ .max_cs = 2,
+ .hastype = false,
+ .mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_ast2600_start,
+ .segment_end = aspeed_spi_segment_ast2600_end,
+ .segment_reg = aspeed_spi_segment_ast2600_reg,
+};
+
+static const struct of_device_id aspeed_spi_matches[] = {
+ { .compatible = "aspeed,ast2400-fmc", .data = &ast2400_fmc_data },
+ { .compatible = "aspeed,ast2500-fmc", .data = &ast2500_fmc_data },
+ { .compatible = "aspeed,ast2500-spi", .data = &ast2500_spi_data },
+ { .compatible = "aspeed,ast2600-fmc", .data = &ast2600_fmc_data },
+ { .compatible = "aspeed,ast2600-spi", .data = &ast2600_spi_data },
+ { }
+};
+MODULE_DEVICE_TABLE(of, aspeed_spi_matches);
+
+static struct platform_driver aspeed_spi_driver = {
+ .probe = aspeed_spi_probe,
+ .remove = aspeed_spi_remove,
+ .driver = {
+ .name = DEVICE_NAME,
+ .of_match_table = aspeed_spi_matches,
+ }
+};
+
+module_platform_driver(aspeed_spi_driver);
+
+MODULE_DESCRIPTION("ASPEED Static Memory Controller Driver");
+MODULE_AUTHOR("Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>");
+MODULE_AUTHOR("Cedric Le Goater <clg@kaod.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig b/drivers/mtd/spi-nor/controllers/Kconfig
index 876a47042fec..35f18c01b1d8 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config SPI_ASPEED_SMC_MTD_SPI_NOR
tristate "Aspeed flash controllers in SPI mode"
- depends on ARCH_ASPEED || COMPILE_TEST
+ depends on (ARCH_ASPEED && !SPI_ASPEED_SMC) || COMPILE_TEST
depends on HAS_IOMEM && OF
help
This enables support for the Firmware Memory controller (FMC)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 83e352b0c8f9..dc44493439fb 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -101,6 +101,17 @@ config SPI_ARMADA_3700
This enables support for the SPI controller present on the
Marvell Armada 3700 SoCs.
+config SPI_ASPEED_SMC
+ tristate "Aspeed flash controllers in SPI mode"
+ depends on (ARCH_ASPEED && !CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR) || COMPILE_TEST
+ depends on OF
+ help
+ This enables support for the Firmware Memory controller (FMC)
+ in the Aspeed AST2600, AST2500 and AST2400 SoCs when attached
+ to SPI NOR chips, and support for the SPI flash memory
+ controller (SPI) for the host firmware. The implementation
+ only supports SPI NOR.
+
config SPI_ATMEL
tristate "Atmel SPI Controller"
depends on ARCH_AT91 || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 699db95c8441..3dd0e649be94 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SPI_ALTERA_CORE) += spi-altera-core.o
obj-$(CONFIG_SPI_ALTERA_DFL) += spi-altera-dfl.o
obj-$(CONFIG_SPI_AR934X) += spi-ar934x.o
obj-$(CONFIG_SPI_ARMADA_3700) += spi-armada-3700.o
+obj-$(CONFIG_SPI_ASPEED_SMC) += spi-aspeed-smc.o
obj-$(CONFIG_SPI_ATMEL) += spi-atmel.o
obj-$(CONFIG_SPI_ATMEL_QUADSPI) += atmel-quadspi.o
obj-$(CONFIG_SPI_AT91_USART) += spi-at91-usart.o
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
This SPI driver adds support for the Aspeed static memory controllers
of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
* AST2600 Firmware SPI Memory Controller (FMC)
. BMC firmware
. 3 chip select pins (CE0 ~ CE2)
. Only supports SPI type flash memory
. different segment register interface
. single, dual and quad mode.
* AST2600 SPI Flash Controller (SPI1 and SPI2)
. host firmware
. 2 chip select pins (CE0 ~ CE1)
. different segment register interface
. single, dual and quad mode.
* AST2500 Firmware SPI Memory Controller (FMC)
. BMC firmware
. 3 chip select pins (CE0 ~ CE2)
. supports SPI type flash memory (CE0-CE1)
. CE2 can be of NOR type flash but this is not supported by the driver
. single, dual mode.
* AST2500 SPI Flash Controller (SPI1 and SPI2)
. host firmware
. 2 chip select pins (CE0 ~ CE1)
. single, dual mode.
* AST2400 New Static Memory Controller (also referred as FMC)
. BMC firmware
. New register set
. 5 chip select pins (CE0 ∼ CE4)
. supports NOR flash, NAND flash and SPI flash memory.
. single, dual and quad mode.
Each controller has a memory range on which flash devices contents are
mapped. Each device is assigned a window that can be changed at bootime
with the Segment Address Registers.
Each SPI flash device can then be accessed in two modes: Command and
User. When in User mode, SPI transfers are initiated with accesses to
the memory segment of a device. When in Command mode, memory
operations on the memory segment of a device generate SPI commands
automatically using a Control Register for the settings.
This initial patch adds support for User mode. Command mode needs a little
more work to check that the memory window on the AHB bus fits the device
size. It will come later when support for direct mapping is added.
Single and dual mode RX transfers are supported. Other types than SPI
are not supported.
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 766 ++++++++++++++++++++++++
drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
4 files changed, 779 insertions(+), 1 deletion(-)
create mode 100644 drivers/spi/spi-aspeed-smc.c
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
new file mode 100644
index 000000000000..0aeff6f468af
--- /dev/null
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -0,0 +1,766 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * ASPEED FMC/SPI Memory Controller Driver
+ *
+ * Copyright (c) 2015-2022, IBM Corporation.
+ * Copyright (c) 2020, ASPEED Corporation.
+ */
+
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spi-mem.h>
+
+#define DEVICE_NAME "spi-aspeed-smc"
+
+#define ASPEED_SPI_DEFAULT_FREQ 50000000
+
+/* Type setting Register */
+#define CONFIG_REG 0x0
+#define CONFIG_TYPE_SPI 0x2
+
+/* CE Control Register */
+#define CE_CTRL_REG 0x4
+
+/* CEx Control Register */
+#define CE0_CTRL_REG 0x10
+#define CTRL_IO_MODE_MASK GENMASK(30, 28)
+#define CTRL_IO_SINGLE_DATA 0x0
+#define CTRL_IO_DUAL_DATA BIT(29)
+#define CTRL_IO_QUAD_DATA BIT(30)
+#define CTRL_COMMAND_SHIFT 16
+#define CTRL_IO_DUMMY_SET(dummy) \
+ (((((dummy) >> 2) & 0x1) << 14) | (((dummy) & 0x3) << 6))
+#define CTRL_CE_STOP_ACTIVE BIT(2)
+#define CTRL_IO_MODE_CMD_MASK GENMASK(1, 0)
+#define CTRL_IO_MODE_NORMAL 0x0
+#define CTRL_IO_MODE_READ 0x1
+#define CTRL_IO_MODE_WRITE 0x2
+#define CTRL_IO_MODE_USER 0x3
+
+#define CTRL_IO_CMD_MASK 0xf0ff40c3
+
+/* CEx Address Decoding Range Register */
+#define CE0_SEGMENT_ADDR_REG 0x30
+
+enum aspeed_spi_ctl_reg_value {
+ ASPEED_SPI_BASE,
+ ASPEED_SPI_READ,
+ ASPEED_SPI_WRITE,
+ ASPEED_SPI_MAX,
+};
+
+struct aspeed_spi;
+
+struct aspeed_spi_chip {
+ struct aspeed_spi *aspi;
+ u32 cs;
+ void __iomem *ctl;
+ void __iomem *ahb_base;
+ u32 ahb_window_size;
+ u32 ctl_val[ASPEED_SPI_MAX];
+ u32 clk_freq;
+};
+
+struct aspeed_spi_data {
+ u32 ctl0;
+ u32 max_cs;
+ bool hastype;
+ u32 mode_bits;
+ u32 we0;
+
+ u32 (*segment_start)(struct aspeed_spi *aspi, u32 reg);
+ u32 (*segment_end)(struct aspeed_spi *aspi, u32 reg);
+ u32 (*segment_reg)(struct aspeed_spi *aspi, u32 start, u32 end);
+};
+
+#define ASPEED_SPI_MAX_NUM_CS 5
+
+struct aspeed_spi {
+ const struct aspeed_spi_data *data;
+
+ void __iomem *regs;
+ void __iomem *ahb_base;
+ u32 ahb_base_phy;
+ u32 ahb_window_size;
+ u32 num_cs;
+ struct device *dev;
+
+ struct clk *clk;
+ u32 clk_freq;
+
+ struct aspeed_spi_chip chips[ASPEED_SPI_MAX_NUM_CS];
+};
+
+static u32 aspeed_spi_get_io_mode(const struct spi_mem_op *op)
+{
+ switch (op->data.buswidth) {
+ case 1:
+ return CTRL_IO_SINGLE_DATA;
+ case 2:
+ return CTRL_IO_DUAL_DATA;
+ case 4:
+ return CTRL_IO_QUAD_DATA;
+ default:
+ return CTRL_IO_SINGLE_DATA;
+ }
+}
+
+static void aspeed_spi_set_io_mode(struct aspeed_spi_chip *chip, u32 io_mode)
+{
+ u32 ctl;
+
+ if (io_mode > 0) {
+ ctl = readl(chip->ctl) & ~CTRL_IO_MODE_MASK;
+ ctl |= io_mode;
+ writel(ctl, chip->ctl);
+ }
+}
+
+static inline u32 aspeed_spi_chip_write_bit(struct aspeed_spi_chip *chip)
+{
+ return BIT(chip->aspi->data->we0 + chip->cs);
+}
+
+static void aspeed_spi_chip_enable(struct aspeed_spi_chip *chip, bool enable)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ u32 reg = readl(aspi->regs + CONFIG_REG);
+
+ if (enable)
+ reg |= aspeed_spi_chip_write_bit(chip);
+ else
+ reg &= ~aspeed_spi_chip_write_bit(chip);
+ writel(reg, aspi->regs + CONFIG_REG);
+}
+
+static void aspeed_spi_start_user(struct aspeed_spi_chip *chip)
+{
+ u32 ctl = chip->ctl_val[ASPEED_SPI_BASE];
+
+ ctl |= CTRL_IO_MODE_USER | CTRL_CE_STOP_ACTIVE;
+ writel(ctl, chip->ctl);
+
+ ctl &= ~CTRL_CE_STOP_ACTIVE;
+ writel(ctl, chip->ctl);
+}
+
+static void aspeed_spi_stop_user(struct aspeed_spi_chip *chip)
+{
+ u32 ctl = chip->ctl_val[ASPEED_SPI_READ] |
+ CTRL_IO_MODE_USER | CTRL_CE_STOP_ACTIVE;
+
+ writel(ctl, chip->ctl);
+
+ /* Restore defaults */
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+}
+
+static int aspeed_spi_read_from_ahb(void *buf, void __iomem *src, size_t len)
+{
+ size_t offset = 0;
+
+ if (IS_ALIGNED((uintptr_t)src, sizeof(uintptr_t)) &&
+ IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t))) {
+ ioread32_rep(src, buf, len >> 2);
+ offset = len & ~0x3;
+ len -= offset;
+ }
+ ioread8_rep(src, (u8 *)buf + offset, len);
+ return 0;
+}
+
+static int aspeed_spi_write_to_ahb(void __iomem *dst, const void *buf, size_t len)
+{
+ size_t offset = 0;
+
+ if (IS_ALIGNED((uintptr_t)dst, sizeof(uintptr_t)) &&
+ IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t))) {
+ iowrite32_rep(dst, buf, len >> 2);
+ offset = len & ~0x3;
+ len -= offset;
+ }
+ iowrite8_rep(dst, (const u8 *)buf + offset, len);
+ return 0;
+}
+
+static void aspeed_spi_send_cmd_addr(struct aspeed_spi_chip *chip, u8 addr_nbytes,
+ u64 offset, u32 opcode)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ __be32 temp;
+ u32 cmdaddr;
+
+ switch (addr_nbytes) {
+ default:
+ dev_warn_once(aspi->dev, "Unexpected address width %u, defaulting to 3",
+ addr_nbytes);
+ fallthrough;
+ case 3:
+ cmdaddr = offset & 0xFFFFFF;
+ cmdaddr |= opcode << 24;
+
+ temp = cpu_to_be32(cmdaddr);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &temp, 4);
+ break;
+ case 4:
+ temp = cpu_to_be32(offset);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &opcode, 1);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &temp, 4);
+ break;
+ }
+}
+
+static int aspeed_spi_read_reg(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op)
+{
+ aspeed_spi_start_user(chip);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &op->cmd.opcode, 1);
+ aspeed_spi_read_from_ahb(op->data.buf.in,
+ chip->ahb_base, op->data.nbytes);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+static int aspeed_spi_write_reg(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op)
+{
+ aspeed_spi_start_user(chip);
+ aspeed_spi_write_to_ahb(chip->ahb_base, &op->cmd.opcode, 1);
+ aspeed_spi_write_to_ahb(chip->ahb_base, op->data.buf.out,
+ op->data.nbytes);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+static ssize_t aspeed_spi_read_user(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op,
+ u64 offset, size_t len, void *buf)
+{
+ int io_mode = aspeed_spi_get_io_mode(op);
+ u8 dummy = 0xFF;
+ int i;
+
+ aspeed_spi_start_user(chip);
+ aspeed_spi_send_cmd_addr(chip, op->addr.nbytes, offset, op->cmd.opcode);
+ if (op->dummy.buswidth && op->dummy.nbytes) {
+ for (i = 0; i < op->dummy.nbytes / op->dummy.buswidth; i++)
+ aspeed_spi_write_to_ahb(chip->ahb_base, &dummy, sizeof(dummy));
+ }
+
+ aspeed_spi_set_io_mode(chip, io_mode);
+
+ aspeed_spi_read_from_ahb(buf, chip->ahb_base, len);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+static ssize_t aspeed_spi_write_user(struct aspeed_spi_chip *chip,
+ const struct spi_mem_op *op)
+{
+ aspeed_spi_start_user(chip);
+ aspeed_spi_send_cmd_addr(chip, op->addr.nbytes, op->addr.val, op->cmd.opcode);
+ aspeed_spi_write_to_ahb(chip->ahb_base, op->data.buf.out, op->data.nbytes);
+ aspeed_spi_stop_user(chip);
+ return 0;
+}
+
+/* support for 1-1-1, 1-1-2 or 1-1-4 */
+static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ if (op->cmd.buswidth > 1)
+ return false;
+
+ if (op->addr.nbytes != 0) {
+ if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
+ return false;
+ }
+
+ if (op->dummy.nbytes != 0) {
+ if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
+ return false;
+ }
+
+ if (op->data.nbytes != 0 && op->data.buswidth > 4)
+ return false;
+
+ if (!spi_mem_default_supports_op(mem, op))
+ return false;
+
+ return true;
+}
+
+static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
+ struct aspeed_spi_chip *chip = &aspi->chips[mem->spi->chip_select];
+ u32 addr_mode, addr_mode_backup;
+ u32 ctl_val;
+ int ret = 0;
+
+ dev_dbg(aspi->dev,
+ "CE%d %s OP %#x mode:%d.%d.%d.%d naddr:%#x ndummies:%#x len:%#x",
+ chip->cs, op->data.dir == SPI_MEM_DATA_IN ? "read" : "write",
+ op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
+ op->dummy.buswidth, op->data.buswidth,
+ op->addr.nbytes, op->dummy.nbytes, op->data.nbytes);
+
+ addr_mode = readl(aspi->regs + CE_CTRL_REG);
+ addr_mode_backup = addr_mode;
+
+ ctl_val = chip->ctl_val[ASPEED_SPI_BASE];
+ ctl_val &= ~CTRL_IO_CMD_MASK;
+
+ ctl_val |= op->cmd.opcode << CTRL_COMMAND_SHIFT;
+
+ /* 4BYTE address mode */
+ if (op->addr.nbytes) {
+ if (op->addr.nbytes == 4)
+ addr_mode |= (0x11 << chip->cs);
+ else
+ addr_mode &= ~(0x11 << chip->cs);
+ }
+
+ if (op->dummy.buswidth && op->dummy.nbytes)
+ ctl_val |= CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth);
+
+ if (op->data.nbytes != 0) {
+ if (op->data.buswidth)
+ ctl_val |= aspeed_spi_get_io_mode(op);
+ }
+
+ if (op->data.dir == SPI_MEM_DATA_OUT)
+ ctl_val |= CTRL_IO_MODE_WRITE;
+ else
+ ctl_val |= CTRL_IO_MODE_READ;
+
+ if (addr_mode != addr_mode_backup)
+ writel(addr_mode, aspi->regs + CE_CTRL_REG);
+ writel(ctl_val, chip->ctl);
+
+ if (op->data.dir == SPI_MEM_DATA_IN) {
+ if (!op->addr.nbytes)
+ ret = aspeed_spi_read_reg(chip, op);
+ else
+ ret = aspeed_spi_read_user(chip, op, op->addr.val,
+ op->data.nbytes, op->data.buf.in);
+ } else {
+ if (!op->addr.nbytes)
+ ret = aspeed_spi_write_reg(chip, op);
+ else
+ ret = aspeed_spi_write_user(chip, op);
+ }
+
+ /* Restore defaults */
+ if (addr_mode != addr_mode_backup)
+ writel(addr_mode_backup, aspi->regs + CE_CTRL_REG);
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+ return ret;
+}
+
+static int aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ int ret;
+
+ ret = do_aspeed_spi_exec_op(mem, op);
+ if (ret)
+ dev_err(&mem->spi->dev, "operation failed: %d\n", ret);
+ return ret;
+}
+
+static const char *aspeed_spi_get_name(struct spi_mem *mem)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
+ struct device *dev = aspi->dev;
+
+ return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev), mem->spi->chip_select);
+}
+
+struct aspeed_spi_window {
+ u32 cs;
+ u32 offset;
+ u32 size;
+};
+
+static void aspeed_spi_get_windows(struct aspeed_spi *aspi,
+ struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS])
+{
+ const struct aspeed_spi_data *data = aspi->data;
+ u32 reg_val;
+ u32 cs;
+
+ for (cs = 0; cs < aspi->data->max_cs; cs++) {
+ reg_val = readl(aspi->regs + CE0_SEGMENT_ADDR_REG + cs * 4);
+ windows[cs].cs = cs;
+ windows[cs].size = data->segment_end(aspi, reg_val) -
+ data->segment_start(aspi, reg_val);
+ windows[cs].offset = cs ? windows[cs - 1].offset + windows[cs - 1].size : 0;
+ dev_vdbg(aspi->dev, "CE%d offset=0x%.8x size=0x%x\n", cs,
+ windows[cs].offset, windows[cs].size);
+ }
+}
+
+/*
+ * On the AST2600, some CE windows are closed by default at reset but
+ * U-Boot should open all.
+ */
+static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS] = { 0 };
+ struct aspeed_spi_window *win = &windows[chip->cs];
+
+ aspeed_spi_get_windows(aspi, windows);
+
+ chip->ahb_base = aspi->ahb_base + win->offset;
+ chip->ahb_window_size = win->size;
+
+ dev_dbg(aspi->dev, "CE%d default window [ 0x%.8x - 0x%.8x ] %dMB",
+ chip->cs, aspi->ahb_base_phy + win->offset,
+ aspi->ahb_base_phy + win->offset + win->size - 1,
+ win->size >> 20);
+
+ return chip->ahb_window_size ? 0 : -1;
+}
+
+static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
+ .supports_op = aspeed_spi_supports_op,
+ .exec_op = aspeed_spi_exec_op,
+ .get_name = aspeed_spi_get_name,
+};
+
+static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ u32 reg;
+
+ reg = readl(aspi->regs + CONFIG_REG);
+ reg &= ~(3 << (chip->cs * 2));
+ reg |= type << (chip->cs * 2);
+ writel(reg, aspi->regs + CONFIG_REG);
+}
+
+static int aspeed_spi_chip_init(struct aspeed_spi_chip *chip)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ const struct aspeed_spi_data *data = aspi->data;
+
+ chip->ctl = aspi->regs + data->ctl0 + chip->cs * 4;
+
+ aspeed_spi_chip_enable(chip, true);
+
+ /* The driver only supports SPI type flash */
+ if (data->hastype)
+ aspeed_spi_chip_set_type(chip, CONFIG_TYPE_SPI);
+
+ if (aspeed_spi_chip_set_default_window(chip) < 0) {
+ dev_warn(aspi->dev, "CE%d window invalid", chip->cs);
+ return -EINVAL;
+ }
+
+ chip->ctl_val[ASPEED_SPI_BASE] = CTRL_CE_STOP_ACTIVE | CTRL_IO_MODE_USER;
+ return 0;
+}
+
+static int aspeed_spi_init_devices(struct platform_device *pdev, struct aspeed_spi *aspi)
+{
+ struct device_node *np;
+ unsigned int cs;
+ int ret;
+
+ for_each_available_child_of_node(aspi->dev->of_node, np) {
+ struct aspeed_spi_chip *chip;
+
+ if (!of_device_is_compatible(np, "jedec,spi-nor"))
+ continue;
+
+ ret = of_property_read_u32(np, "reg", &cs);
+ if (ret) {
+ dev_err(aspi->dev, "Couldn't not read chip select.\n");
+ of_node_put(np);
+ return ret;
+ }
+
+ if (cs > aspi->data->max_cs) {
+ dev_err(aspi->dev, "Chip select %d out of range.\n", cs);
+ of_node_put(np);
+ return -ERANGE;
+ }
+
+ chip = &aspi->chips[cs];
+ chip->aspi = aspi;
+ chip->cs = cs;
+
+ ret = aspeed_spi_chip_init(chip);
+ if (ret) {
+ of_node_put(np);
+ return ret;
+ }
+
+ if (of_property_read_u32(np, "spi-max-frequency", &chip->clk_freq))
+ chip->clk_freq = ASPEED_SPI_DEFAULT_FREQ;
+
+ aspi->num_cs++;
+ }
+
+ return 0;
+}
+
+static void aspeed_spi_enable(struct aspeed_spi *aspi, bool enable)
+{
+ int cs;
+
+ for (cs = 0; cs < aspi->num_cs; cs++)
+ aspeed_spi_chip_enable(&aspi->chips[cs], enable);
+}
+
+static int aspeed_spi_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct aspeed_spi_data *data;
+ struct spi_controller *ctlr;
+ struct aspeed_spi *aspi;
+ struct resource *res;
+ int ret;
+
+ data = of_device_get_match_data(&pdev->dev);
+ if (!data)
+ return -ENODEV;
+
+ ctlr = spi_alloc_master(dev, sizeof(*aspi));
+ if (!ctlr)
+ return -ENOMEM;
+
+ aspi = spi_controller_get_devdata(ctlr);
+ platform_set_drvdata(pdev, aspi);
+ aspi->data = data;
+ aspi->dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ aspi->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(aspi->regs)) {
+ ret = PTR_ERR(aspi->regs);
+ goto put_controller;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ aspi->ahb_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(aspi->ahb_base)) {
+ ret = PTR_ERR(aspi->ahb_base);
+ goto put_controller;
+ }
+
+ aspi->ahb_window_size = resource_size(res);
+ aspi->ahb_base_phy = res->start;
+
+ aspi->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(aspi->clk)) {
+ ret = PTR_ERR(aspi->clk);
+ goto put_controller;
+ }
+
+ aspi->clk_freq = clk_get_rate(aspi->clk);
+ if (!aspi->clk_freq) {
+ ret = -EINVAL;
+ goto put_controller;
+ }
+
+ ret = clk_prepare_enable(aspi->clk);
+ if (ret) {
+ dev_err(dev, "can not enable the clock\n");
+ goto put_controller;
+ }
+
+ ret = aspeed_spi_init_devices(pdev, aspi);
+ if (ret)
+ goto disable_clk;
+
+ if (!aspi->num_cs) {
+ dev_err(&pdev->dev, "no devices ?!\n");
+ ret = -ENODEV;
+ goto disable_clk;
+ }
+
+ /* IRQ is for DMA, which the driver doesn't support yet */
+
+ ctlr->mode_bits = SPI_RX_DUAL | SPI_TX_DUAL | aspi->data->mode_bits;
+ ctlr->bus_num = pdev->id;
+ ctlr->mem_ops = &aspeed_spi_mem_ops;
+ ctlr->num_chipselect = aspi->num_cs;
+ ctlr->dev.of_node = dev->of_node;
+
+ ret = devm_spi_register_controller(dev, ctlr);
+ if (ret) {
+ dev_err(&pdev->dev, "spi_register_controller failed\n");
+ goto disable_aspi;
+ }
+
+ dev_dbg(&pdev->dev, "probed %d devices\n", aspi->num_cs);
+ return 0;
+
+disable_aspi:
+ aspeed_spi_enable(aspi, false);
+disable_clk:
+ clk_disable_unprepare(aspi->clk);
+put_controller:
+ spi_controller_put(ctlr);
+
+ return ret;
+}
+
+static int aspeed_spi_remove(struct platform_device *pdev)
+{
+ struct spi_controller *ctlr = platform_get_drvdata(pdev);
+ struct aspeed_spi *aspi = spi_controller_get_devdata(ctlr);
+
+ aspeed_spi_enable(aspi, false);
+ spi_unregister_controller(ctlr);
+ clk_disable_unprepare(aspi->clk);
+ return 0;
+}
+
+/*
+ * AHB mappings
+ */
+
+/*
+ * The Segment Registers of the AST2400 and AST2500 use a 8MB unit.
+ * The address range is encoded with absolute addresses in the overall
+ * mapping window.
+ */
+static u32 aspeed_spi_segment_start(struct aspeed_spi *aspi, u32 reg)
+{
+ return ((reg >> 16) & 0xFF) << 23;
+}
+
+static u32 aspeed_spi_segment_end(struct aspeed_spi *aspi, u32 reg)
+{
+ return ((reg >> 24) & 0xFF) << 23;
+}
+
+static u32 aspeed_spi_segment_reg(struct aspeed_spi *aspi, u32 start, u32 end)
+{
+ return (((start >> 23) & 0xFF) << 16) | (((end >> 23) & 0xFF) << 24);
+}
+
+/*
+ * The Segment Registers of the AST2600 use a 1MB unit. The address
+ * range is encoded with offsets in the overall mapping window.
+ */
+
+#define AST2600_SEG_ADDR_MASK 0x0ff00000
+
+static u32 aspeed_spi_segment_ast2600_start(struct aspeed_spi *aspi,
+ u32 reg)
+{
+ u32 start_offset = (reg << 16) & AST2600_SEG_ADDR_MASK;
+
+ return aspi->ahb_base_phy + start_offset;
+}
+
+static u32 aspeed_spi_segment_ast2600_end(struct aspeed_spi *aspi,
+ u32 reg)
+{
+ u32 end_offset = reg & AST2600_SEG_ADDR_MASK;
+
+ /* segment is disabled */
+ if (!end_offset)
+ return aspi->ahb_base_phy;
+
+ return aspi->ahb_base_phy + end_offset + 0x100000;
+}
+
+static u32 aspeed_spi_segment_ast2600_reg(struct aspeed_spi *aspi,
+ u32 start, u32 end)
+{
+ /* disable zero size segments */
+ if (start == end)
+ return 0;
+
+ return ((start & AST2600_SEG_ADDR_MASK) >> 16) |
+ ((end - 1) & AST2600_SEG_ADDR_MASK);
+}
+
+/*
+ * Platform definitions
+ */
+static const struct aspeed_spi_data ast2400_fmc_data = {
+ .max_cs = 5,
+ .hastype = true,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_start,
+ .segment_end = aspeed_spi_segment_end,
+ .segment_reg = aspeed_spi_segment_reg,
+};
+
+static const struct aspeed_spi_data ast2500_fmc_data = {
+ .max_cs = 3,
+ .hastype = true,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_start,
+ .segment_end = aspeed_spi_segment_end,
+ .segment_reg = aspeed_spi_segment_reg,
+};
+
+static const struct aspeed_spi_data ast2500_spi_data = {
+ .max_cs = 2,
+ .hastype = false,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_start,
+ .segment_end = aspeed_spi_segment_end,
+ .segment_reg = aspeed_spi_segment_reg,
+};
+
+static const struct aspeed_spi_data ast2600_fmc_data = {
+ .max_cs = 3,
+ .hastype = false,
+ .mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_ast2600_start,
+ .segment_end = aspeed_spi_segment_ast2600_end,
+ .segment_reg = aspeed_spi_segment_ast2600_reg,
+};
+
+static const struct aspeed_spi_data ast2600_spi_data = {
+ .max_cs = 2,
+ .hastype = false,
+ .mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
+ .we0 = 16,
+ .ctl0 = CE0_CTRL_REG,
+ .segment_start = aspeed_spi_segment_ast2600_start,
+ .segment_end = aspeed_spi_segment_ast2600_end,
+ .segment_reg = aspeed_spi_segment_ast2600_reg,
+};
+
+static const struct of_device_id aspeed_spi_matches[] = {
+ { .compatible = "aspeed,ast2400-fmc", .data = &ast2400_fmc_data },
+ { .compatible = "aspeed,ast2500-fmc", .data = &ast2500_fmc_data },
+ { .compatible = "aspeed,ast2500-spi", .data = &ast2500_spi_data },
+ { .compatible = "aspeed,ast2600-fmc", .data = &ast2600_fmc_data },
+ { .compatible = "aspeed,ast2600-spi", .data = &ast2600_spi_data },
+ { }
+};
+MODULE_DEVICE_TABLE(of, aspeed_spi_matches);
+
+static struct platform_driver aspeed_spi_driver = {
+ .probe = aspeed_spi_probe,
+ .remove = aspeed_spi_remove,
+ .driver = {
+ .name = DEVICE_NAME,
+ .of_match_table = aspeed_spi_matches,
+ }
+};
+
+module_platform_driver(aspeed_spi_driver);
+
+MODULE_DESCRIPTION("ASPEED Static Memory Controller Driver");
+MODULE_AUTHOR("Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>");
+MODULE_AUTHOR("Cedric Le Goater <clg@kaod.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig b/drivers/mtd/spi-nor/controllers/Kconfig
index 876a47042fec..35f18c01b1d8 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config SPI_ASPEED_SMC_MTD_SPI_NOR
tristate "Aspeed flash controllers in SPI mode"
- depends on ARCH_ASPEED || COMPILE_TEST
+ depends on (ARCH_ASPEED && !SPI_ASPEED_SMC) || COMPILE_TEST
depends on HAS_IOMEM && OF
help
This enables support for the Firmware Memory controller (FMC)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 83e352b0c8f9..dc44493439fb 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -101,6 +101,17 @@ config SPI_ARMADA_3700
This enables support for the SPI controller present on the
Marvell Armada 3700 SoCs.
+config SPI_ASPEED_SMC
+ tristate "Aspeed flash controllers in SPI mode"
+ depends on (ARCH_ASPEED && !CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR) || COMPILE_TEST
+ depends on OF
+ help
+ This enables support for the Firmware Memory controller (FMC)
+ in the Aspeed AST2600, AST2500 and AST2400 SoCs when attached
+ to SPI NOR chips, and support for the SPI flash memory
+ controller (SPI) for the host firmware. The implementation
+ only supports SPI NOR.
+
config SPI_ATMEL
tristate "Atmel SPI Controller"
depends on ARCH_AT91 || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 699db95c8441..3dd0e649be94 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SPI_ALTERA_CORE) += spi-altera-core.o
obj-$(CONFIG_SPI_ALTERA_DFL) += spi-altera-dfl.o
obj-$(CONFIG_SPI_AR934X) += spi-ar934x.o
obj-$(CONFIG_SPI_ARMADA_3700) += spi-armada-3700.o
+obj-$(CONFIG_SPI_ASPEED_SMC) += spi-aspeed-smc.o
obj-$(CONFIG_SPI_ATMEL) += spi-atmel.o
obj-$(CONFIG_SPI_ATMEL_QUADSPI) += atmel-quadspi.o
obj-$(CONFIG_SPI_AT91_USART) += spi-at91-usart.o
--
2.34.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] 115+ messages in thread
* [PATCH 04/10] spi: aspeed: Add support for direct mapping
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
Use direct mapping to read the flash device contents. This operation
mode is called "Command mode" on Aspeed SoC SMC controllers. It uses a
Control Register for the settings to apply when a memory operation is
performed on the flash device mapping window.
If the window is not big enough, fall back to the "User mode" to
perform the read.
Direct mapping for writes will come later when validated.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 67 ++++++++++++++++++++++++++++++++++--
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 0aeff6f468af..8d33fcb7736a 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -345,8 +345,8 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
if (!op->addr.nbytes)
ret = aspeed_spi_read_reg(chip, op);
else
- ret = aspeed_spi_read_user(chip, op, op->addr.val,
- op->data.nbytes, op->data.buf.in);
+ memcpy_fromio(op->data.buf.in, chip->ahb_base + op->addr.val,
+ op->data.nbytes);
} else {
if (!op->addr.nbytes)
ret = aspeed_spi_write_reg(chip, op);
@@ -426,10 +426,73 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
return chip->ahb_window_size ? 0 : -1;
}
+static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
+ struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
+ struct spi_mem_op *op = &desc->info.op_tmpl;
+ u32 ctl_val;
+ int ret = 0;
+
+ chip->clk_freq = desc->mem->spi->max_speed_hz;
+
+ /* Only for reads */
+ if (op->data.dir != SPI_MEM_DATA_IN)
+ return -EOPNOTSUPP;
+
+ if (desc->info.length > chip->ahb_window_size)
+ dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
+ chip->cs, chip->ahb_window_size >> 20);
+
+ /* Define the default IO read settings */
+ ctl_val = readl(chip->ctl) & ~CTRL_IO_CMD_MASK;
+ ctl_val |= aspeed_spi_get_io_mode(op) |
+ op->cmd.opcode << CTRL_COMMAND_SHIFT |
+ CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth) |
+ CTRL_IO_MODE_READ;
+
+ /* Tune 4BYTE address mode */
+ if (op->addr.nbytes) {
+ u32 addr_mode = readl(aspi->regs + CE_CTRL_REG);
+
+ if (op->addr.nbytes == 4)
+ addr_mode |= (0x11 << chip->cs);
+ else
+ addr_mode &= ~(0x11 << chip->cs);
+ writel(addr_mode, aspi->regs + CE_CTRL_REG);
+ }
+
+ /* READ mode is the controller default setting */
+ chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+
+ dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
+ chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
+
+ return ret;
+}
+
+static int aspeed_spi_dirmap_read(struct spi_mem_dirmap_desc *desc,
+ u64 offset, size_t len, void *buf)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
+ struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
+
+ /* Switch to USER command mode if mapping window is too small */
+ if (chip->ahb_window_size < offset + len)
+ aspeed_spi_read_user(chip, &desc->info.op_tmpl, offset, len, buf);
+ else
+ memcpy_fromio(buf, chip->ahb_base + offset, len);
+
+ return len;
+}
+
static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
.supports_op = aspeed_spi_supports_op,
.exec_op = aspeed_spi_exec_op,
.get_name = aspeed_spi_get_name,
+ .dirmap_create = aspeed_spi_dirmap_create,
+ .dirmap_read = aspeed_spi_dirmap_read,
};
static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 04/10] spi: aspeed: Add support for direct mapping
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
Use direct mapping to read the flash device contents. This operation
mode is called "Command mode" on Aspeed SoC SMC controllers. It uses a
Control Register for the settings to apply when a memory operation is
performed on the flash device mapping window.
If the window is not big enough, fall back to the "User mode" to
perform the read.
Direct mapping for writes will come later when validated.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 67 ++++++++++++++++++++++++++++++++++--
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 0aeff6f468af..8d33fcb7736a 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -345,8 +345,8 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
if (!op->addr.nbytes)
ret = aspeed_spi_read_reg(chip, op);
else
- ret = aspeed_spi_read_user(chip, op, op->addr.val,
- op->data.nbytes, op->data.buf.in);
+ memcpy_fromio(op->data.buf.in, chip->ahb_base + op->addr.val,
+ op->data.nbytes);
} else {
if (!op->addr.nbytes)
ret = aspeed_spi_write_reg(chip, op);
@@ -426,10 +426,73 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
return chip->ahb_window_size ? 0 : -1;
}
+static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
+ struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
+ struct spi_mem_op *op = &desc->info.op_tmpl;
+ u32 ctl_val;
+ int ret = 0;
+
+ chip->clk_freq = desc->mem->spi->max_speed_hz;
+
+ /* Only for reads */
+ if (op->data.dir != SPI_MEM_DATA_IN)
+ return -EOPNOTSUPP;
+
+ if (desc->info.length > chip->ahb_window_size)
+ dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
+ chip->cs, chip->ahb_window_size >> 20);
+
+ /* Define the default IO read settings */
+ ctl_val = readl(chip->ctl) & ~CTRL_IO_CMD_MASK;
+ ctl_val |= aspeed_spi_get_io_mode(op) |
+ op->cmd.opcode << CTRL_COMMAND_SHIFT |
+ CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth) |
+ CTRL_IO_MODE_READ;
+
+ /* Tune 4BYTE address mode */
+ if (op->addr.nbytes) {
+ u32 addr_mode = readl(aspi->regs + CE_CTRL_REG);
+
+ if (op->addr.nbytes == 4)
+ addr_mode |= (0x11 << chip->cs);
+ else
+ addr_mode &= ~(0x11 << chip->cs);
+ writel(addr_mode, aspi->regs + CE_CTRL_REG);
+ }
+
+ /* READ mode is the controller default setting */
+ chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+
+ dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
+ chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
+
+ return ret;
+}
+
+static int aspeed_spi_dirmap_read(struct spi_mem_dirmap_desc *desc,
+ u64 offset, size_t len, void *buf)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
+ struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
+
+ /* Switch to USER command mode if mapping window is too small */
+ if (chip->ahb_window_size < offset + len)
+ aspeed_spi_read_user(chip, &desc->info.op_tmpl, offset, len, buf);
+ else
+ memcpy_fromio(buf, chip->ahb_base + offset, len);
+
+ return len;
+}
+
static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
.supports_op = aspeed_spi_supports_op,
.exec_op = aspeed_spi_exec_op,
.get_name = aspeed_spi_get_name,
+ .dirmap_create = aspeed_spi_dirmap_create,
+ .dirmap_read = aspeed_spi_dirmap_read,
};
static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 04/10] spi: aspeed: Add support for direct mapping
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
Use direct mapping to read the flash device contents. This operation
mode is called "Command mode" on Aspeed SoC SMC controllers. It uses a
Control Register for the settings to apply when a memory operation is
performed on the flash device mapping window.
If the window is not big enough, fall back to the "User mode" to
perform the read.
Direct mapping for writes will come later when validated.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 67 ++++++++++++++++++++++++++++++++++--
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 0aeff6f468af..8d33fcb7736a 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -345,8 +345,8 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
if (!op->addr.nbytes)
ret = aspeed_spi_read_reg(chip, op);
else
- ret = aspeed_spi_read_user(chip, op, op->addr.val,
- op->data.nbytes, op->data.buf.in);
+ memcpy_fromio(op->data.buf.in, chip->ahb_base + op->addr.val,
+ op->data.nbytes);
} else {
if (!op->addr.nbytes)
ret = aspeed_spi_write_reg(chip, op);
@@ -426,10 +426,73 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
return chip->ahb_window_size ? 0 : -1;
}
+static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
+ struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
+ struct spi_mem_op *op = &desc->info.op_tmpl;
+ u32 ctl_val;
+ int ret = 0;
+
+ chip->clk_freq = desc->mem->spi->max_speed_hz;
+
+ /* Only for reads */
+ if (op->data.dir != SPI_MEM_DATA_IN)
+ return -EOPNOTSUPP;
+
+ if (desc->info.length > chip->ahb_window_size)
+ dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
+ chip->cs, chip->ahb_window_size >> 20);
+
+ /* Define the default IO read settings */
+ ctl_val = readl(chip->ctl) & ~CTRL_IO_CMD_MASK;
+ ctl_val |= aspeed_spi_get_io_mode(op) |
+ op->cmd.opcode << CTRL_COMMAND_SHIFT |
+ CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth) |
+ CTRL_IO_MODE_READ;
+
+ /* Tune 4BYTE address mode */
+ if (op->addr.nbytes) {
+ u32 addr_mode = readl(aspi->regs + CE_CTRL_REG);
+
+ if (op->addr.nbytes == 4)
+ addr_mode |= (0x11 << chip->cs);
+ else
+ addr_mode &= ~(0x11 << chip->cs);
+ writel(addr_mode, aspi->regs + CE_CTRL_REG);
+ }
+
+ /* READ mode is the controller default setting */
+ chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+
+ dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
+ chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
+
+ return ret;
+}
+
+static int aspeed_spi_dirmap_read(struct spi_mem_dirmap_desc *desc,
+ u64 offset, size_t len, void *buf)
+{
+ struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
+ struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
+
+ /* Switch to USER command mode if mapping window is too small */
+ if (chip->ahb_window_size < offset + len)
+ aspeed_spi_read_user(chip, &desc->info.op_tmpl, offset, len, buf);
+ else
+ memcpy_fromio(buf, chip->ahb_base + offset, len);
+
+ return len;
+}
+
static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
.supports_op = aspeed_spi_supports_op,
.exec_op = aspeed_spi_exec_op,
.get_name = aspeed_spi_get_name,
+ .dirmap_create = aspeed_spi_dirmap_create,
+ .dirmap_read = aspeed_spi_dirmap_read,
};
static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
--
2.34.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] 115+ messages in thread
* [PATCH 05/10] spi: aspeed: Adjust direct mapping to device size
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
The segment registers of the FMC/SPI controllers provide a way to
configure the mapping window of the flash device contents on the AHB
bus. Adjust this window to the size of the spi-mem mapping.
Things get more complex with multiple devices. The driver needs to
also adjust the window of the next device to make sure that there is
no overlap, even if there is no available device. The proposal below
is not perfect but it is covering all the cases we have seen on
different boards with one and two devices on the same bus.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 88 ++++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 8d33fcb7736a..9c4eacfed72c 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -426,6 +426,92 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
return chip->ahb_window_size ? 0 : -1;
}
+static int aspeed_spi_set_window(struct aspeed_spi *aspi,
+ const struct aspeed_spi_window *win)
+{
+ u32 start = aspi->ahb_base_phy + win->offset;
+ u32 end = start + win->size;
+ void __iomem *seg_reg = aspi->regs + CE0_SEGMENT_ADDR_REG + win->cs * 4;
+ u32 seg_val_backup = readl(seg_reg);
+ u32 seg_val = aspi->data->segment_reg(aspi, start, end);
+
+ if (seg_val == seg_val_backup)
+ return 0;
+
+ writel(seg_val, seg_reg);
+
+ /*
+ * Restore initial value if something goes wrong else we could
+ * loose access to the chip.
+ */
+ if (seg_val != readl(seg_reg)) {
+ dev_err(aspi->dev, "CE%d invalid window [ 0x%.8x - 0x%.8x ] %dMB",
+ win->cs, start, end - 1, win->size >> 20);
+ writel(seg_val_backup, seg_reg);
+ return -EIO;
+ }
+
+ if (win->size)
+ dev_dbg(aspi->dev, "CE%d new window [ 0x%.8x - 0x%.8x ] %dMB",
+ win->cs, start, end - 1, win->size >> 20);
+ else
+ dev_dbg(aspi->dev, "CE%d window closed", win->cs);
+
+ return 0;
+}
+
+/*
+ * Yet to be done when possible :
+ * - Align mappings on flash size (we don't have the info)
+ * - ioremap each window, not strictly necessary since the overall window
+ * is correct.
+ */
+static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
+ u32 local_offset, u32 size)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS] = { 0 };
+ struct aspeed_spi_window *win = &windows[chip->cs];
+ int ret;
+
+ aspeed_spi_get_windows(aspi, windows);
+
+ /* Adjust this chip window */
+ win->offset += local_offset;
+ win->size = size;
+
+ if (win->offset + win->size > aspi->ahb_window_size) {
+ win->size = aspi->ahb_window_size - win->offset;
+ dev_warn(aspi->dev, "CE%d window resized to %dMB", chip->cs, win->size >> 20);
+ }
+
+ ret = aspeed_spi_set_window(aspi, win);
+ if (ret)
+ return ret;
+
+ /* Update chip mapping info */
+ chip->ahb_base = aspi->ahb_base + win->offset;
+ chip->ahb_window_size = win->size;
+
+ /*
+ * Also adjust next chip window to make sure that it does not
+ * overlap with the current window.
+ */
+ if (chip->cs < aspi->data->max_cs - 1) {
+ struct aspeed_spi_window *next = &windows[chip->cs + 1];
+
+ /* Change offset and size to keep the same end address */
+ if ((next->offset + next->size) > (win->offset + win->size))
+ next->size = (next->offset + next->size) - (win->offset + win->size);
+ else
+ next->size = 0;
+ next->offset = win->offset + win->size;
+
+ aspeed_spi_set_window(aspi, next);
+ }
+ return 0;
+}
+
static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
{
struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
@@ -440,6 +526,8 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
if (op->data.dir != SPI_MEM_DATA_IN)
return -EOPNOTSUPP;
+ aspeed_spi_chip_adjust_window(chip, desc->info.offset, desc->info.length);
+
if (desc->info.length > chip->ahb_window_size)
dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
chip->cs, chip->ahb_window_size >> 20);
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 05/10] spi: aspeed: Adjust direct mapping to device size
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
The segment registers of the FMC/SPI controllers provide a way to
configure the mapping window of the flash device contents on the AHB
bus. Adjust this window to the size of the spi-mem mapping.
Things get more complex with multiple devices. The driver needs to
also adjust the window of the next device to make sure that there is
no overlap, even if there is no available device. The proposal below
is not perfect but it is covering all the cases we have seen on
different boards with one and two devices on the same bus.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 88 ++++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 8d33fcb7736a..9c4eacfed72c 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -426,6 +426,92 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
return chip->ahb_window_size ? 0 : -1;
}
+static int aspeed_spi_set_window(struct aspeed_spi *aspi,
+ const struct aspeed_spi_window *win)
+{
+ u32 start = aspi->ahb_base_phy + win->offset;
+ u32 end = start + win->size;
+ void __iomem *seg_reg = aspi->regs + CE0_SEGMENT_ADDR_REG + win->cs * 4;
+ u32 seg_val_backup = readl(seg_reg);
+ u32 seg_val = aspi->data->segment_reg(aspi, start, end);
+
+ if (seg_val == seg_val_backup)
+ return 0;
+
+ writel(seg_val, seg_reg);
+
+ /*
+ * Restore initial value if something goes wrong else we could
+ * loose access to the chip.
+ */
+ if (seg_val != readl(seg_reg)) {
+ dev_err(aspi->dev, "CE%d invalid window [ 0x%.8x - 0x%.8x ] %dMB",
+ win->cs, start, end - 1, win->size >> 20);
+ writel(seg_val_backup, seg_reg);
+ return -EIO;
+ }
+
+ if (win->size)
+ dev_dbg(aspi->dev, "CE%d new window [ 0x%.8x - 0x%.8x ] %dMB",
+ win->cs, start, end - 1, win->size >> 20);
+ else
+ dev_dbg(aspi->dev, "CE%d window closed", win->cs);
+
+ return 0;
+}
+
+/*
+ * Yet to be done when possible :
+ * - Align mappings on flash size (we don't have the info)
+ * - ioremap each window, not strictly necessary since the overall window
+ * is correct.
+ */
+static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
+ u32 local_offset, u32 size)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS] = { 0 };
+ struct aspeed_spi_window *win = &windows[chip->cs];
+ int ret;
+
+ aspeed_spi_get_windows(aspi, windows);
+
+ /* Adjust this chip window */
+ win->offset += local_offset;
+ win->size = size;
+
+ if (win->offset + win->size > aspi->ahb_window_size) {
+ win->size = aspi->ahb_window_size - win->offset;
+ dev_warn(aspi->dev, "CE%d window resized to %dMB", chip->cs, win->size >> 20);
+ }
+
+ ret = aspeed_spi_set_window(aspi, win);
+ if (ret)
+ return ret;
+
+ /* Update chip mapping info */
+ chip->ahb_base = aspi->ahb_base + win->offset;
+ chip->ahb_window_size = win->size;
+
+ /*
+ * Also adjust next chip window to make sure that it does not
+ * overlap with the current window.
+ */
+ if (chip->cs < aspi->data->max_cs - 1) {
+ struct aspeed_spi_window *next = &windows[chip->cs + 1];
+
+ /* Change offset and size to keep the same end address */
+ if ((next->offset + next->size) > (win->offset + win->size))
+ next->size = (next->offset + next->size) - (win->offset + win->size);
+ else
+ next->size = 0;
+ next->offset = win->offset + win->size;
+
+ aspeed_spi_set_window(aspi, next);
+ }
+ return 0;
+}
+
static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
{
struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
@@ -440,6 +526,8 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
if (op->data.dir != SPI_MEM_DATA_IN)
return -EOPNOTSUPP;
+ aspeed_spi_chip_adjust_window(chip, desc->info.offset, desc->info.length);
+
if (desc->info.length > chip->ahb_window_size)
dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
chip->cs, chip->ahb_window_size >> 20);
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 05/10] spi: aspeed: Adjust direct mapping to device size
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
The segment registers of the FMC/SPI controllers provide a way to
configure the mapping window of the flash device contents on the AHB
bus. Adjust this window to the size of the spi-mem mapping.
Things get more complex with multiple devices. The driver needs to
also adjust the window of the next device to make sure that there is
no overlap, even if there is no available device. The proposal below
is not perfect but it is covering all the cases we have seen on
different boards with one and two devices on the same bus.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 88 ++++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 8d33fcb7736a..9c4eacfed72c 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -426,6 +426,92 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
return chip->ahb_window_size ? 0 : -1;
}
+static int aspeed_spi_set_window(struct aspeed_spi *aspi,
+ const struct aspeed_spi_window *win)
+{
+ u32 start = aspi->ahb_base_phy + win->offset;
+ u32 end = start + win->size;
+ void __iomem *seg_reg = aspi->regs + CE0_SEGMENT_ADDR_REG + win->cs * 4;
+ u32 seg_val_backup = readl(seg_reg);
+ u32 seg_val = aspi->data->segment_reg(aspi, start, end);
+
+ if (seg_val == seg_val_backup)
+ return 0;
+
+ writel(seg_val, seg_reg);
+
+ /*
+ * Restore initial value if something goes wrong else we could
+ * loose access to the chip.
+ */
+ if (seg_val != readl(seg_reg)) {
+ dev_err(aspi->dev, "CE%d invalid window [ 0x%.8x - 0x%.8x ] %dMB",
+ win->cs, start, end - 1, win->size >> 20);
+ writel(seg_val_backup, seg_reg);
+ return -EIO;
+ }
+
+ if (win->size)
+ dev_dbg(aspi->dev, "CE%d new window [ 0x%.8x - 0x%.8x ] %dMB",
+ win->cs, start, end - 1, win->size >> 20);
+ else
+ dev_dbg(aspi->dev, "CE%d window closed", win->cs);
+
+ return 0;
+}
+
+/*
+ * Yet to be done when possible :
+ * - Align mappings on flash size (we don't have the info)
+ * - ioremap each window, not strictly necessary since the overall window
+ * is correct.
+ */
+static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
+ u32 local_offset, u32 size)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS] = { 0 };
+ struct aspeed_spi_window *win = &windows[chip->cs];
+ int ret;
+
+ aspeed_spi_get_windows(aspi, windows);
+
+ /* Adjust this chip window */
+ win->offset += local_offset;
+ win->size = size;
+
+ if (win->offset + win->size > aspi->ahb_window_size) {
+ win->size = aspi->ahb_window_size - win->offset;
+ dev_warn(aspi->dev, "CE%d window resized to %dMB", chip->cs, win->size >> 20);
+ }
+
+ ret = aspeed_spi_set_window(aspi, win);
+ if (ret)
+ return ret;
+
+ /* Update chip mapping info */
+ chip->ahb_base = aspi->ahb_base + win->offset;
+ chip->ahb_window_size = win->size;
+
+ /*
+ * Also adjust next chip window to make sure that it does not
+ * overlap with the current window.
+ */
+ if (chip->cs < aspi->data->max_cs - 1) {
+ struct aspeed_spi_window *next = &windows[chip->cs + 1];
+
+ /* Change offset and size to keep the same end address */
+ if ((next->offset + next->size) > (win->offset + win->size))
+ next->size = (next->offset + next->size) - (win->offset + win->size);
+ else
+ next->size = 0;
+ next->offset = win->offset + win->size;
+
+ aspeed_spi_set_window(aspi, next);
+ }
+ return 0;
+}
+
static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
{
struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
@@ -440,6 +526,8 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
if (op->data.dir != SPI_MEM_DATA_IN)
return -EOPNOTSUPP;
+ aspeed_spi_chip_adjust_window(chip, desc->info.offset, desc->info.length);
+
if (desc->info.length > chip->ahb_window_size)
dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
chip->cs, chip->ahb_window_size >> 20);
--
2.34.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] 115+ messages in thread
* [PATCH 06/10] spi: aspeed: Workaround AST2500 limitations
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
It is not possible to configure a full 128MB window for a chip of the
same size on the AST2500 SPI controller. For his case, the maximum
window size is restricted to 120MB for CE0.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 9c4eacfed72c..c6ac3253d7d5 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -466,6 +466,8 @@ static int aspeed_spi_set_window(struct aspeed_spi *aspi,
* - ioremap each window, not strictly necessary since the overall window
* is correct.
*/
+static const struct aspeed_spi_data ast2500_spi_data;
+
static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
u32 local_offset, u32 size)
{
@@ -474,6 +476,16 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
struct aspeed_spi_window *win = &windows[chip->cs];
int ret;
+ /*
+ * Due to an HW issue on the AST2500 SPI controller, the CE0
+ * window size should be smaller than the maximum 128MB.
+ */
+ if (aspi->data == &ast2500_spi_data && chip->cs == 0 && size == SZ_128M) {
+ size = 120 << 20;
+ dev_info(aspi->dev, "CE%d window resized to %dMB (AST2500 HW quirk)",
+ chip->cs, size >> 20);
+ }
+
aspeed_spi_get_windows(aspi, windows);
/* Adjust this chip window */
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 06/10] spi: aspeed: Workaround AST2500 limitations
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
It is not possible to configure a full 128MB window for a chip of the
same size on the AST2500 SPI controller. For his case, the maximum
window size is restricted to 120MB for CE0.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 9c4eacfed72c..c6ac3253d7d5 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -466,6 +466,8 @@ static int aspeed_spi_set_window(struct aspeed_spi *aspi,
* - ioremap each window, not strictly necessary since the overall window
* is correct.
*/
+static const struct aspeed_spi_data ast2500_spi_data;
+
static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
u32 local_offset, u32 size)
{
@@ -474,6 +476,16 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
struct aspeed_spi_window *win = &windows[chip->cs];
int ret;
+ /*
+ * Due to an HW issue on the AST2500 SPI controller, the CE0
+ * window size should be smaller than the maximum 128MB.
+ */
+ if (aspi->data == &ast2500_spi_data && chip->cs == 0 && size == SZ_128M) {
+ size = 120 << 20;
+ dev_info(aspi->dev, "CE%d window resized to %dMB (AST2500 HW quirk)",
+ chip->cs, size >> 20);
+ }
+
aspeed_spi_get_windows(aspi, windows);
/* Adjust this chip window */
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 06/10] spi: aspeed: Workaround AST2500 limitations
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
It is not possible to configure a full 128MB window for a chip of the
same size on the AST2500 SPI controller. For his case, the maximum
window size is restricted to 120MB for CE0.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 9c4eacfed72c..c6ac3253d7d5 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -466,6 +466,8 @@ static int aspeed_spi_set_window(struct aspeed_spi *aspi,
* - ioremap each window, not strictly necessary since the overall window
* is correct.
*/
+static const struct aspeed_spi_data ast2500_spi_data;
+
static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
u32 local_offset, u32 size)
{
@@ -474,6 +476,16 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
struct aspeed_spi_window *win = &windows[chip->cs];
int ret;
+ /*
+ * Due to an HW issue on the AST2500 SPI controller, the CE0
+ * window size should be smaller than the maximum 128MB.
+ */
+ if (aspi->data == &ast2500_spi_data && chip->cs == 0 && size == SZ_128M) {
+ size = 120 << 20;
+ dev_info(aspi->dev, "CE%d window resized to %dMB (AST2500 HW quirk)",
+ chip->cs, size >> 20);
+ }
+
aspeed_spi_get_windows(aspi, windows);
/* Adjust this chip window */
--
2.34.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] 115+ messages in thread
* [PATCH 07/10] spi: aspeed: Add support for the AST2400 SPI controller
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
Extend the driver for the AST2400 SPI Flash Controller (SPI). This
controller has a slightly different interface which requires
adaptation of the 4B handling. Summary of features :
. host Firmware
. 1 chip select pin (CE0)
. slightly different register set, between AST2500 and the legacy
controller
. no segment registers
. single, dual mode.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index c6ac3253d7d5..e44e80bab50f 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -32,6 +32,7 @@
#define CTRL_IO_DUAL_DATA BIT(29)
#define CTRL_IO_QUAD_DATA BIT(30)
#define CTRL_COMMAND_SHIFT 16
+#define CTRL_IO_ADDRESS_4B BIT(13) /* AST2400 SPI only */
#define CTRL_IO_DUMMY_SET(dummy) \
(((((dummy) >> 2) & 0x1) << 14) | (((dummy) & 0x3) << 6))
#define CTRL_CE_STOP_ACTIVE BIT(2)
@@ -293,6 +294,8 @@ static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op
return true;
}
+static const struct aspeed_spi_data ast2400_spi_data;
+
static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
{
struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
@@ -322,6 +325,9 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
addr_mode |= (0x11 << chip->cs);
else
addr_mode &= ~(0x11 << chip->cs);
+
+ if (op->addr.nbytes == 4 && chip->aspi->data == &ast2400_spi_data)
+ ctl_val |= CTRL_IO_ADDRESS_4B;
}
if (op->dummy.buswidth && op->dummy.nbytes)
@@ -413,7 +419,13 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS] = { 0 };
struct aspeed_spi_window *win = &windows[chip->cs];
- aspeed_spi_get_windows(aspi, windows);
+ /* No segment registers for the AST2400 SPI controller */
+ if (aspi->data == &ast2400_spi_data) {
+ win->offset = 0;
+ win->size = aspi->ahb_window_size;
+ } else {
+ aspeed_spi_get_windows(aspi, windows);
+ }
chip->ahb_base = aspi->ahb_base + win->offset;
chip->ahb_window_size = win->size;
@@ -476,6 +488,10 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
struct aspeed_spi_window *win = &windows[chip->cs];
int ret;
+ /* No segment registers for the AST2400 SPI controller */
+ if (aspi->data == &ast2400_spi_data)
+ return 0;
+
/*
* Due to an HW issue on the AST2500 SPI controller, the CE0
* window size should be smaller than the maximum 128MB.
@@ -560,6 +576,12 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
else
addr_mode &= ~(0x11 << chip->cs);
writel(addr_mode, aspi->regs + CE_CTRL_REG);
+
+ /* AST2400 SPI controller sets 4BYTE address mode in
+ * CE0 Control Register
+ */
+ if (op->addr.nbytes == 4 && chip->aspi->data == &ast2400_spi_data)
+ ctl_val |= CTRL_IO_ADDRESS_4B;
}
/* READ mode is the controller default setting */
@@ -860,6 +882,14 @@ static const struct aspeed_spi_data ast2400_fmc_data = {
.segment_reg = aspeed_spi_segment_reg,
};
+static const struct aspeed_spi_data ast2400_spi_data = {
+ .max_cs = 1,
+ .hastype = false,
+ .we0 = 0,
+ .ctl0 = 0x04,
+ /* No segment registers */
+};
+
static const struct aspeed_spi_data ast2500_fmc_data = {
.max_cs = 3,
.hastype = true,
@@ -904,6 +934,7 @@ static const struct aspeed_spi_data ast2600_spi_data = {
static const struct of_device_id aspeed_spi_matches[] = {
{ .compatible = "aspeed,ast2400-fmc", .data = &ast2400_fmc_data },
+ { .compatible = "aspeed,ast2400-spi", .data = &ast2400_spi_data },
{ .compatible = "aspeed,ast2500-fmc", .data = &ast2500_fmc_data },
{ .compatible = "aspeed,ast2500-spi", .data = &ast2500_spi_data },
{ .compatible = "aspeed,ast2600-fmc", .data = &ast2600_fmc_data },
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 07/10] spi: aspeed: Add support for the AST2400 SPI controller
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
Extend the driver for the AST2400 SPI Flash Controller (SPI). This
controller has a slightly different interface which requires
adaptation of the 4B handling. Summary of features :
. host Firmware
. 1 chip select pin (CE0)
. slightly different register set, between AST2500 and the legacy
controller
. no segment registers
. single, dual mode.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index c6ac3253d7d5..e44e80bab50f 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -32,6 +32,7 @@
#define CTRL_IO_DUAL_DATA BIT(29)
#define CTRL_IO_QUAD_DATA BIT(30)
#define CTRL_COMMAND_SHIFT 16
+#define CTRL_IO_ADDRESS_4B BIT(13) /* AST2400 SPI only */
#define CTRL_IO_DUMMY_SET(dummy) \
(((((dummy) >> 2) & 0x1) << 14) | (((dummy) & 0x3) << 6))
#define CTRL_CE_STOP_ACTIVE BIT(2)
@@ -293,6 +294,8 @@ static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op
return true;
}
+static const struct aspeed_spi_data ast2400_spi_data;
+
static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
{
struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
@@ -322,6 +325,9 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
addr_mode |= (0x11 << chip->cs);
else
addr_mode &= ~(0x11 << chip->cs);
+
+ if (op->addr.nbytes == 4 && chip->aspi->data == &ast2400_spi_data)
+ ctl_val |= CTRL_IO_ADDRESS_4B;
}
if (op->dummy.buswidth && op->dummy.nbytes)
@@ -413,7 +419,13 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS] = { 0 };
struct aspeed_spi_window *win = &windows[chip->cs];
- aspeed_spi_get_windows(aspi, windows);
+ /* No segment registers for the AST2400 SPI controller */
+ if (aspi->data == &ast2400_spi_data) {
+ win->offset = 0;
+ win->size = aspi->ahb_window_size;
+ } else {
+ aspeed_spi_get_windows(aspi, windows);
+ }
chip->ahb_base = aspi->ahb_base + win->offset;
chip->ahb_window_size = win->size;
@@ -476,6 +488,10 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
struct aspeed_spi_window *win = &windows[chip->cs];
int ret;
+ /* No segment registers for the AST2400 SPI controller */
+ if (aspi->data == &ast2400_spi_data)
+ return 0;
+
/*
* Due to an HW issue on the AST2500 SPI controller, the CE0
* window size should be smaller than the maximum 128MB.
@@ -560,6 +576,12 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
else
addr_mode &= ~(0x11 << chip->cs);
writel(addr_mode, aspi->regs + CE_CTRL_REG);
+
+ /* AST2400 SPI controller sets 4BYTE address mode in
+ * CE0 Control Register
+ */
+ if (op->addr.nbytes == 4 && chip->aspi->data == &ast2400_spi_data)
+ ctl_val |= CTRL_IO_ADDRESS_4B;
}
/* READ mode is the controller default setting */
@@ -860,6 +882,14 @@ static const struct aspeed_spi_data ast2400_fmc_data = {
.segment_reg = aspeed_spi_segment_reg,
};
+static const struct aspeed_spi_data ast2400_spi_data = {
+ .max_cs = 1,
+ .hastype = false,
+ .we0 = 0,
+ .ctl0 = 0x04,
+ /* No segment registers */
+};
+
static const struct aspeed_spi_data ast2500_fmc_data = {
.max_cs = 3,
.hastype = true,
@@ -904,6 +934,7 @@ static const struct aspeed_spi_data ast2600_spi_data = {
static const struct of_device_id aspeed_spi_matches[] = {
{ .compatible = "aspeed,ast2400-fmc", .data = &ast2400_fmc_data },
+ { .compatible = "aspeed,ast2400-spi", .data = &ast2400_spi_data },
{ .compatible = "aspeed,ast2500-fmc", .data = &ast2500_fmc_data },
{ .compatible = "aspeed,ast2500-spi", .data = &ast2500_spi_data },
{ .compatible = "aspeed,ast2600-fmc", .data = &ast2600_fmc_data },
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 07/10] spi: aspeed: Add support for the AST2400 SPI controller
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
Extend the driver for the AST2400 SPI Flash Controller (SPI). This
controller has a slightly different interface which requires
adaptation of the 4B handling. Summary of features :
. host Firmware
. 1 chip select pin (CE0)
. slightly different register set, between AST2500 and the legacy
controller
. no segment registers
. single, dual mode.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index c6ac3253d7d5..e44e80bab50f 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -32,6 +32,7 @@
#define CTRL_IO_DUAL_DATA BIT(29)
#define CTRL_IO_QUAD_DATA BIT(30)
#define CTRL_COMMAND_SHIFT 16
+#define CTRL_IO_ADDRESS_4B BIT(13) /* AST2400 SPI only */
#define CTRL_IO_DUMMY_SET(dummy) \
(((((dummy) >> 2) & 0x1) << 14) | (((dummy) & 0x3) << 6))
#define CTRL_CE_STOP_ACTIVE BIT(2)
@@ -293,6 +294,8 @@ static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op
return true;
}
+static const struct aspeed_spi_data ast2400_spi_data;
+
static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
{
struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
@@ -322,6 +325,9 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
addr_mode |= (0x11 << chip->cs);
else
addr_mode &= ~(0x11 << chip->cs);
+
+ if (op->addr.nbytes == 4 && chip->aspi->data == &ast2400_spi_data)
+ ctl_val |= CTRL_IO_ADDRESS_4B;
}
if (op->dummy.buswidth && op->dummy.nbytes)
@@ -413,7 +419,13 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
struct aspeed_spi_window windows[ASPEED_SPI_MAX_NUM_CS] = { 0 };
struct aspeed_spi_window *win = &windows[chip->cs];
- aspeed_spi_get_windows(aspi, windows);
+ /* No segment registers for the AST2400 SPI controller */
+ if (aspi->data == &ast2400_spi_data) {
+ win->offset = 0;
+ win->size = aspi->ahb_window_size;
+ } else {
+ aspeed_spi_get_windows(aspi, windows);
+ }
chip->ahb_base = aspi->ahb_base + win->offset;
chip->ahb_window_size = win->size;
@@ -476,6 +488,10 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
struct aspeed_spi_window *win = &windows[chip->cs];
int ret;
+ /* No segment registers for the AST2400 SPI controller */
+ if (aspi->data == &ast2400_spi_data)
+ return 0;
+
/*
* Due to an HW issue on the AST2500 SPI controller, the CE0
* window size should be smaller than the maximum 128MB.
@@ -560,6 +576,12 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
else
addr_mode &= ~(0x11 << chip->cs);
writel(addr_mode, aspi->regs + CE_CTRL_REG);
+
+ /* AST2400 SPI controller sets 4BYTE address mode in
+ * CE0 Control Register
+ */
+ if (op->addr.nbytes == 4 && chip->aspi->data == &ast2400_spi_data)
+ ctl_val |= CTRL_IO_ADDRESS_4B;
}
/* READ mode is the controller default setting */
@@ -860,6 +882,14 @@ static const struct aspeed_spi_data ast2400_fmc_data = {
.segment_reg = aspeed_spi_segment_reg,
};
+static const struct aspeed_spi_data ast2400_spi_data = {
+ .max_cs = 1,
+ .hastype = false,
+ .we0 = 0,
+ .ctl0 = 0x04,
+ /* No segment registers */
+};
+
static const struct aspeed_spi_data ast2500_fmc_data = {
.max_cs = 3,
.hastype = true,
@@ -904,6 +934,7 @@ static const struct aspeed_spi_data ast2600_spi_data = {
static const struct of_device_id aspeed_spi_matches[] = {
{ .compatible = "aspeed,ast2400-fmc", .data = &ast2400_fmc_data },
+ { .compatible = "aspeed,ast2400-spi", .data = &ast2400_spi_data },
{ .compatible = "aspeed,ast2500-fmc", .data = &ast2500_fmc_data },
{ .compatible = "aspeed,ast2500-spi", .data = &ast2500_spi_data },
{ .compatible = "aspeed,ast2600-fmc", .data = &ast2600_fmc_data },
--
2.34.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] 115+ messages in thread
* [PATCH 08/10] spi: aspeed: Calibrate read timings
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
To accommodate the different response time of SPI transfers on different
boards and different SPI NOR devices, the Aspeed controllers provide a
set of Read Timing Compensation registers to tune the timing delays
depending on the frequency being used. The AST2600 SoC has one of
these registers per device. On the AST2500 and AST2400 SoCs, the
timing register is shared by all devices which is a bit problematic to
get good results other than for one device.
The algorithm first reads a golden buffer at low speed and then performs
reads with different clocks and delay cycle settings to find a breaking
point. This selects a default good frequency for the CEx control register.
The current settings are bit optimistic as we pick the first delay giving
good results. A safer approach would be to determine an interval and
choose the middle value.
Due to the lack of API, calibration is performed when the direct mapping
for reads is created.
Cc: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 281 +++++++++++++++++++++++++++++++++++
1 file changed, 281 insertions(+)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index e44e80bab50f..a08c20308404 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -35,6 +35,8 @@
#define CTRL_IO_ADDRESS_4B BIT(13) /* AST2400 SPI only */
#define CTRL_IO_DUMMY_SET(dummy) \
(((((dummy) >> 2) & 0x1) << 14) | (((dummy) & 0x3) << 6))
+#define CTRL_FREQ_SEL_SHIFT 8
+#define CTRL_FREQ_SEL_MASK GENMASK(11, CTRL_FREQ_SEL_SHIFT)
#define CTRL_CE_STOP_ACTIVE BIT(2)
#define CTRL_IO_MODE_CMD_MASK GENMASK(1, 0)
#define CTRL_IO_MODE_NORMAL 0x0
@@ -47,6 +49,9 @@
/* CEx Address Decoding Range Register */
#define CE0_SEGMENT_ADDR_REG 0x30
+/* CEx Read timing compensation register */
+#define CE0_TIMING_COMPENSATION_REG 0x94
+
enum aspeed_spi_ctl_reg_value {
ASPEED_SPI_BASE,
ASPEED_SPI_READ,
@@ -72,10 +77,15 @@ struct aspeed_spi_data {
bool hastype;
u32 mode_bits;
u32 we0;
+ u32 timing;
+ u32 hclk_mask;
+ u32 hdiv_max;
u32 (*segment_start)(struct aspeed_spi *aspi, u32 reg);
u32 (*segment_end)(struct aspeed_spi *aspi, u32 reg);
u32 (*segment_reg)(struct aspeed_spi *aspi, u32 start, u32 end);
+ int (*calibrate)(struct aspeed_spi_chip *chip, u32 hdiv,
+ const u8 *golden_buf, u8 *test_buf);
};
#define ASPEED_SPI_MAX_NUM_CS 5
@@ -540,6 +550,8 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
return 0;
}
+static int aspeed_spi_do_calibration(struct aspeed_spi_chip *chip);
+
static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
{
struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
@@ -588,6 +600,8 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+ ret = aspeed_spi_do_calibration(chip);
+
dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
@@ -869,6 +883,249 @@ static u32 aspeed_spi_segment_ast2600_reg(struct aspeed_spi *aspi,
((end - 1) & AST2600_SEG_ADDR_MASK);
}
+/*
+ * Read timing compensation sequences
+ */
+
+#define CALIBRATE_BUF_SIZE SZ_16K
+
+static bool aspeed_spi_check_reads(struct aspeed_spi_chip *chip,
+ const u8 *golden_buf, u8 *test_buf)
+{
+ int i;
+
+ for (i = 0; i < 10; i++) {
+ memcpy_fromio(test_buf, chip->ahb_base, CALIBRATE_BUF_SIZE);
+ if (memcmp(test_buf, golden_buf, CALIBRATE_BUF_SIZE) != 0) {
+#if defined(VERBOSE_DEBUG)
+ print_hex_dump_bytes(DEVICE_NAME " fail: ", DUMP_PREFIX_NONE,
+ test_buf, 0x100);
+#endif
+ return false;
+ }
+ }
+ return true;
+}
+
+#define FREAD_TPASS(i) (((i) / 2) | (((i) & 1) ? 0 : 8))
+
+/*
+ * The timing register is shared by all devices. Only update for CE0.
+ */
+static int aspeed_spi_calibrate(struct aspeed_spi_chip *chip, u32 hdiv,
+ const u8 *golden_buf, u8 *test_buf)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ const struct aspeed_spi_data *data = aspi->data;
+ int i;
+ int good_pass = -1, pass_count = 0;
+ u32 shift = (hdiv - 1) << 2;
+ u32 mask = ~(0xfu << shift);
+ u32 fread_timing_val = 0;
+
+ /* Try HCLK delay 0..5, each one with/without delay and look for a
+ * good pair.
+ */
+ for (i = 0; i < 12; i++) {
+ bool pass;
+
+ if (chip->cs == 0) {
+ fread_timing_val &= mask;
+ fread_timing_val |= FREAD_TPASS(i) << shift;
+ writel(fread_timing_val, aspi->regs + data->timing);
+ }
+ pass = aspeed_spi_check_reads(chip, golden_buf, test_buf);
+ dev_dbg(aspi->dev,
+ " * [%08x] %d HCLK delay, %dns DI delay : %s",
+ fread_timing_val, i / 2, (i & 1) ? 0 : 4,
+ pass ? "PASS" : "FAIL");
+ if (pass) {
+ pass_count++;
+ if (pass_count == 3) {
+ good_pass = i - 1;
+ break;
+ }
+ } else {
+ pass_count = 0;
+ }
+ }
+
+ /* No good setting for this frequency */
+ if (good_pass < 0)
+ return -1;
+
+ /* We have at least one pass of margin, let's use first pass */
+ if (chip->cs == 0) {
+ fread_timing_val &= mask;
+ fread_timing_val |= FREAD_TPASS(good_pass) << shift;
+ writel(fread_timing_val, aspi->regs + data->timing);
+ }
+ dev_dbg(aspi->dev, " * -> good is pass %d [0x%08x]",
+ good_pass, fread_timing_val);
+ return 0;
+}
+
+static bool aspeed_spi_check_calib_data(const u8 *test_buf, u32 size)
+{
+ const u32 *tb32 = (const u32 *)test_buf;
+ u32 i, cnt = 0;
+
+ /* We check if we have enough words that are neither all 0
+ * nor all 1's so the calibration can be considered valid.
+ *
+ * I use an arbitrary threshold for now of 64
+ */
+ size >>= 2;
+ for (i = 0; i < size; i++) {
+ if (tb32[i] != 0 && tb32[i] != 0xffffffff)
+ cnt++;
+ }
+ return cnt >= 64;
+}
+
+static const u32 aspeed_spi_hclk_divs[] = {
+ 0xf, /* HCLK */
+ 0x7, /* HCLK/2 */
+ 0xe, /* HCLK/3 */
+ 0x6, /* HCLK/4 */
+ 0xd, /* HCLK/5 */
+};
+
+#define ASPEED_SPI_HCLK_DIV(i) \
+ (aspeed_spi_hclk_divs[(i) - 1] << CTRL_FREQ_SEL_SHIFT)
+
+static int aspeed_spi_do_calibration(struct aspeed_spi_chip *chip)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ const struct aspeed_spi_data *data = aspi->data;
+ u32 ahb_freq = aspi->clk_freq;
+ u32 max_freq = chip->clk_freq;
+ u32 ctl_val;
+ u8 *golden_buf = NULL;
+ u8 *test_buf = NULL;
+ int i, rc, best_div = -1;
+
+ dev_dbg(aspi->dev, "calculate timing compensation - AHB freq: %d MHz",
+ ahb_freq / 1000000);
+
+ /*
+ * use the related low frequency to get check calibration data
+ * and get golden data.
+ */
+ ctl_val = chip->ctl_val[ASPEED_SPI_READ] & data->hclk_mask;
+ writel(ctl_val, chip->ctl);
+
+ test_buf = kzalloc(CALIBRATE_BUF_SIZE * 2, GFP_KERNEL);
+ if (!test_buf)
+ return -ENOMEM;
+
+ golden_buf = test_buf + CALIBRATE_BUF_SIZE;
+
+ memcpy_fromio(golden_buf, chip->ahb_base, CALIBRATE_BUF_SIZE);
+ if (!aspeed_spi_check_calib_data(golden_buf, CALIBRATE_BUF_SIZE)) {
+ dev_info(aspi->dev, "Calibration area too uniform, using low speed");
+ goto no_calib;
+ }
+
+#if defined(VERBOSE_DEBUG)
+ print_hex_dump_bytes(DEVICE_NAME " good: ", DUMP_PREFIX_NONE,
+ golden_buf, 0x100);
+#endif
+
+ /* Now we iterate the HCLK dividers until we find our breaking point */
+ for (i = ARRAY_SIZE(aspeed_spi_hclk_divs); i > data->hdiv_max - 1; i--) {
+ u32 tv, freq;
+
+ freq = ahb_freq / i;
+ if (freq > max_freq)
+ continue;
+
+ /* Set the timing */
+ tv = chip->ctl_val[ASPEED_SPI_READ] | ASPEED_SPI_HCLK_DIV(i);
+ writel(tv, chip->ctl);
+ dev_dbg(aspi->dev, "Trying HCLK/%d [%08x] ...", i, tv);
+ rc = data->calibrate(chip, i, golden_buf, test_buf);
+ if (rc == 0)
+ best_div = i;
+ }
+
+ /* Nothing found ? */
+ if (best_div < 0) {
+ dev_warn(aspi->dev, "No good frequency, using dumb slow");
+ } else {
+ dev_dbg(aspi->dev, "Found good read timings at HCLK/%d", best_div);
+
+ /* Record the freq */
+ for (i = 0; i < ASPEED_SPI_MAX; i++)
+ chip->ctl_val[i] = (chip->ctl_val[i] & data->hclk_mask) |
+ ASPEED_SPI_HCLK_DIV(best_div);
+ }
+
+no_calib:
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+ kfree(test_buf);
+ return 0;
+}
+
+#define TIMING_DELAY_DI BIT(3)
+#define TIMING_DELAY_HCYCLE_MAX 5
+#define TIMING_REG_AST2600(chip) \
+ ((chip)->aspi->regs + (chip)->aspi->data->timing + \
+ (chip)->cs * 4)
+
+static int aspeed_spi_ast2600_calibrate(struct aspeed_spi_chip *chip, u32 hdiv,
+ const u8 *golden_buf, u8 *test_buf)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ int hcycle;
+ u32 shift = (hdiv - 2) << 3;
+ u32 mask = ~(0xfu << shift);
+ u32 fread_timing_val = 0;
+
+ for (hcycle = 0; hcycle <= TIMING_DELAY_HCYCLE_MAX; hcycle++) {
+ int delay_ns;
+ bool pass = false;
+
+ fread_timing_val &= mask;
+ fread_timing_val |= hcycle << shift;
+
+ /* no DI input delay first */
+ writel(fread_timing_val, TIMING_REG_AST2600(chip));
+ pass = aspeed_spi_check_reads(chip, golden_buf, test_buf);
+ dev_dbg(aspi->dev,
+ " * [%08x] %d HCLK delay, DI delay none : %s",
+ fread_timing_val, hcycle, pass ? "PASS" : "FAIL");
+ if (pass)
+ return 0;
+
+ /* Add DI input delays */
+ fread_timing_val &= mask;
+ fread_timing_val |= (TIMING_DELAY_DI | hcycle) << shift;
+
+ for (delay_ns = 0; delay_ns < 0x10; delay_ns++) {
+ fread_timing_val &= ~(0xf << (4 + shift));
+ fread_timing_val |= delay_ns << (4 + shift);
+
+ writel(fread_timing_val, TIMING_REG_AST2600(chip));
+ pass = aspeed_spi_check_reads(chip, golden_buf, test_buf);
+ dev_dbg(aspi->dev,
+ " * [%08x] %d HCLK delay, DI delay %d.%dns : %s",
+ fread_timing_val, hcycle, (delay_ns + 1) / 2,
+ (delay_ns + 1) & 1 ? 5 : 5, pass ? "PASS" : "FAIL");
+ /*
+ * TODO: This is optimistic. We should look
+ * for a working interval and save the middle
+ * value in the read timing register.
+ */
+ if (pass)
+ return 0;
+ }
+ }
+
+ /* No good setting for this frequency */
+ return -1;
+}
+
/*
* Platform definitions
*/
@@ -877,6 +1134,10 @@ static const struct aspeed_spi_data ast2400_fmc_data = {
.hastype = true,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
.segment_start = aspeed_spi_segment_start,
.segment_end = aspeed_spi_segment_end,
.segment_reg = aspeed_spi_segment_reg,
@@ -887,6 +1148,10 @@ static const struct aspeed_spi_data ast2400_spi_data = {
.hastype = false,
.we0 = 0,
.ctl0 = 0x04,
+ .timing = 0x14,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
/* No segment registers */
};
@@ -895,6 +1160,10 @@ static const struct aspeed_spi_data ast2500_fmc_data = {
.hastype = true,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
.segment_start = aspeed_spi_segment_start,
.segment_end = aspeed_spi_segment_end,
.segment_reg = aspeed_spi_segment_reg,
@@ -905,6 +1174,10 @@ static const struct aspeed_spi_data ast2500_spi_data = {
.hastype = false,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
.segment_start = aspeed_spi_segment_start,
.segment_end = aspeed_spi_segment_end,
.segment_reg = aspeed_spi_segment_reg,
@@ -916,6 +1189,10 @@ static const struct aspeed_spi_data ast2600_fmc_data = {
.mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xf0fff0ff,
+ .hdiv_max = 2,
+ .calibrate = aspeed_spi_ast2600_calibrate,
.segment_start = aspeed_spi_segment_ast2600_start,
.segment_end = aspeed_spi_segment_ast2600_end,
.segment_reg = aspeed_spi_segment_ast2600_reg,
@@ -927,6 +1204,10 @@ static const struct aspeed_spi_data ast2600_spi_data = {
.mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xf0fff0ff,
+ .hdiv_max = 2,
+ .calibrate = aspeed_spi_ast2600_calibrate,
.segment_start = aspeed_spi_segment_ast2600_start,
.segment_end = aspeed_spi_segment_ast2600_end,
.segment_reg = aspeed_spi_segment_ast2600_reg,
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 08/10] spi: aspeed: Calibrate read timings
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
To accommodate the different response time of SPI transfers on different
boards and different SPI NOR devices, the Aspeed controllers provide a
set of Read Timing Compensation registers to tune the timing delays
depending on the frequency being used. The AST2600 SoC has one of
these registers per device. On the AST2500 and AST2400 SoCs, the
timing register is shared by all devices which is a bit problematic to
get good results other than for one device.
The algorithm first reads a golden buffer at low speed and then performs
reads with different clocks and delay cycle settings to find a breaking
point. This selects a default good frequency for the CEx control register.
The current settings are bit optimistic as we pick the first delay giving
good results. A safer approach would be to determine an interval and
choose the middle value.
Due to the lack of API, calibration is performed when the direct mapping
for reads is created.
Cc: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 281 +++++++++++++++++++++++++++++++++++
1 file changed, 281 insertions(+)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index e44e80bab50f..a08c20308404 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -35,6 +35,8 @@
#define CTRL_IO_ADDRESS_4B BIT(13) /* AST2400 SPI only */
#define CTRL_IO_DUMMY_SET(dummy) \
(((((dummy) >> 2) & 0x1) << 14) | (((dummy) & 0x3) << 6))
+#define CTRL_FREQ_SEL_SHIFT 8
+#define CTRL_FREQ_SEL_MASK GENMASK(11, CTRL_FREQ_SEL_SHIFT)
#define CTRL_CE_STOP_ACTIVE BIT(2)
#define CTRL_IO_MODE_CMD_MASK GENMASK(1, 0)
#define CTRL_IO_MODE_NORMAL 0x0
@@ -47,6 +49,9 @@
/* CEx Address Decoding Range Register */
#define CE0_SEGMENT_ADDR_REG 0x30
+/* CEx Read timing compensation register */
+#define CE0_TIMING_COMPENSATION_REG 0x94
+
enum aspeed_spi_ctl_reg_value {
ASPEED_SPI_BASE,
ASPEED_SPI_READ,
@@ -72,10 +77,15 @@ struct aspeed_spi_data {
bool hastype;
u32 mode_bits;
u32 we0;
+ u32 timing;
+ u32 hclk_mask;
+ u32 hdiv_max;
u32 (*segment_start)(struct aspeed_spi *aspi, u32 reg);
u32 (*segment_end)(struct aspeed_spi *aspi, u32 reg);
u32 (*segment_reg)(struct aspeed_spi *aspi, u32 start, u32 end);
+ int (*calibrate)(struct aspeed_spi_chip *chip, u32 hdiv,
+ const u8 *golden_buf, u8 *test_buf);
};
#define ASPEED_SPI_MAX_NUM_CS 5
@@ -540,6 +550,8 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
return 0;
}
+static int aspeed_spi_do_calibration(struct aspeed_spi_chip *chip);
+
static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
{
struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
@@ -588,6 +600,8 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+ ret = aspeed_spi_do_calibration(chip);
+
dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
@@ -869,6 +883,249 @@ static u32 aspeed_spi_segment_ast2600_reg(struct aspeed_spi *aspi,
((end - 1) & AST2600_SEG_ADDR_MASK);
}
+/*
+ * Read timing compensation sequences
+ */
+
+#define CALIBRATE_BUF_SIZE SZ_16K
+
+static bool aspeed_spi_check_reads(struct aspeed_spi_chip *chip,
+ const u8 *golden_buf, u8 *test_buf)
+{
+ int i;
+
+ for (i = 0; i < 10; i++) {
+ memcpy_fromio(test_buf, chip->ahb_base, CALIBRATE_BUF_SIZE);
+ if (memcmp(test_buf, golden_buf, CALIBRATE_BUF_SIZE) != 0) {
+#if defined(VERBOSE_DEBUG)
+ print_hex_dump_bytes(DEVICE_NAME " fail: ", DUMP_PREFIX_NONE,
+ test_buf, 0x100);
+#endif
+ return false;
+ }
+ }
+ return true;
+}
+
+#define FREAD_TPASS(i) (((i) / 2) | (((i) & 1) ? 0 : 8))
+
+/*
+ * The timing register is shared by all devices. Only update for CE0.
+ */
+static int aspeed_spi_calibrate(struct aspeed_spi_chip *chip, u32 hdiv,
+ const u8 *golden_buf, u8 *test_buf)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ const struct aspeed_spi_data *data = aspi->data;
+ int i;
+ int good_pass = -1, pass_count = 0;
+ u32 shift = (hdiv - 1) << 2;
+ u32 mask = ~(0xfu << shift);
+ u32 fread_timing_val = 0;
+
+ /* Try HCLK delay 0..5, each one with/without delay and look for a
+ * good pair.
+ */
+ for (i = 0; i < 12; i++) {
+ bool pass;
+
+ if (chip->cs == 0) {
+ fread_timing_val &= mask;
+ fread_timing_val |= FREAD_TPASS(i) << shift;
+ writel(fread_timing_val, aspi->regs + data->timing);
+ }
+ pass = aspeed_spi_check_reads(chip, golden_buf, test_buf);
+ dev_dbg(aspi->dev,
+ " * [%08x] %d HCLK delay, %dns DI delay : %s",
+ fread_timing_val, i / 2, (i & 1) ? 0 : 4,
+ pass ? "PASS" : "FAIL");
+ if (pass) {
+ pass_count++;
+ if (pass_count == 3) {
+ good_pass = i - 1;
+ break;
+ }
+ } else {
+ pass_count = 0;
+ }
+ }
+
+ /* No good setting for this frequency */
+ if (good_pass < 0)
+ return -1;
+
+ /* We have at least one pass of margin, let's use first pass */
+ if (chip->cs == 0) {
+ fread_timing_val &= mask;
+ fread_timing_val |= FREAD_TPASS(good_pass) << shift;
+ writel(fread_timing_val, aspi->regs + data->timing);
+ }
+ dev_dbg(aspi->dev, " * -> good is pass %d [0x%08x]",
+ good_pass, fread_timing_val);
+ return 0;
+}
+
+static bool aspeed_spi_check_calib_data(const u8 *test_buf, u32 size)
+{
+ const u32 *tb32 = (const u32 *)test_buf;
+ u32 i, cnt = 0;
+
+ /* We check if we have enough words that are neither all 0
+ * nor all 1's so the calibration can be considered valid.
+ *
+ * I use an arbitrary threshold for now of 64
+ */
+ size >>= 2;
+ for (i = 0; i < size; i++) {
+ if (tb32[i] != 0 && tb32[i] != 0xffffffff)
+ cnt++;
+ }
+ return cnt >= 64;
+}
+
+static const u32 aspeed_spi_hclk_divs[] = {
+ 0xf, /* HCLK */
+ 0x7, /* HCLK/2 */
+ 0xe, /* HCLK/3 */
+ 0x6, /* HCLK/4 */
+ 0xd, /* HCLK/5 */
+};
+
+#define ASPEED_SPI_HCLK_DIV(i) \
+ (aspeed_spi_hclk_divs[(i) - 1] << CTRL_FREQ_SEL_SHIFT)
+
+static int aspeed_spi_do_calibration(struct aspeed_spi_chip *chip)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ const struct aspeed_spi_data *data = aspi->data;
+ u32 ahb_freq = aspi->clk_freq;
+ u32 max_freq = chip->clk_freq;
+ u32 ctl_val;
+ u8 *golden_buf = NULL;
+ u8 *test_buf = NULL;
+ int i, rc, best_div = -1;
+
+ dev_dbg(aspi->dev, "calculate timing compensation - AHB freq: %d MHz",
+ ahb_freq / 1000000);
+
+ /*
+ * use the related low frequency to get check calibration data
+ * and get golden data.
+ */
+ ctl_val = chip->ctl_val[ASPEED_SPI_READ] & data->hclk_mask;
+ writel(ctl_val, chip->ctl);
+
+ test_buf = kzalloc(CALIBRATE_BUF_SIZE * 2, GFP_KERNEL);
+ if (!test_buf)
+ return -ENOMEM;
+
+ golden_buf = test_buf + CALIBRATE_BUF_SIZE;
+
+ memcpy_fromio(golden_buf, chip->ahb_base, CALIBRATE_BUF_SIZE);
+ if (!aspeed_spi_check_calib_data(golden_buf, CALIBRATE_BUF_SIZE)) {
+ dev_info(aspi->dev, "Calibration area too uniform, using low speed");
+ goto no_calib;
+ }
+
+#if defined(VERBOSE_DEBUG)
+ print_hex_dump_bytes(DEVICE_NAME " good: ", DUMP_PREFIX_NONE,
+ golden_buf, 0x100);
+#endif
+
+ /* Now we iterate the HCLK dividers until we find our breaking point */
+ for (i = ARRAY_SIZE(aspeed_spi_hclk_divs); i > data->hdiv_max - 1; i--) {
+ u32 tv, freq;
+
+ freq = ahb_freq / i;
+ if (freq > max_freq)
+ continue;
+
+ /* Set the timing */
+ tv = chip->ctl_val[ASPEED_SPI_READ] | ASPEED_SPI_HCLK_DIV(i);
+ writel(tv, chip->ctl);
+ dev_dbg(aspi->dev, "Trying HCLK/%d [%08x] ...", i, tv);
+ rc = data->calibrate(chip, i, golden_buf, test_buf);
+ if (rc == 0)
+ best_div = i;
+ }
+
+ /* Nothing found ? */
+ if (best_div < 0) {
+ dev_warn(aspi->dev, "No good frequency, using dumb slow");
+ } else {
+ dev_dbg(aspi->dev, "Found good read timings at HCLK/%d", best_div);
+
+ /* Record the freq */
+ for (i = 0; i < ASPEED_SPI_MAX; i++)
+ chip->ctl_val[i] = (chip->ctl_val[i] & data->hclk_mask) |
+ ASPEED_SPI_HCLK_DIV(best_div);
+ }
+
+no_calib:
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+ kfree(test_buf);
+ return 0;
+}
+
+#define TIMING_DELAY_DI BIT(3)
+#define TIMING_DELAY_HCYCLE_MAX 5
+#define TIMING_REG_AST2600(chip) \
+ ((chip)->aspi->regs + (chip)->aspi->data->timing + \
+ (chip)->cs * 4)
+
+static int aspeed_spi_ast2600_calibrate(struct aspeed_spi_chip *chip, u32 hdiv,
+ const u8 *golden_buf, u8 *test_buf)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ int hcycle;
+ u32 shift = (hdiv - 2) << 3;
+ u32 mask = ~(0xfu << shift);
+ u32 fread_timing_val = 0;
+
+ for (hcycle = 0; hcycle <= TIMING_DELAY_HCYCLE_MAX; hcycle++) {
+ int delay_ns;
+ bool pass = false;
+
+ fread_timing_val &= mask;
+ fread_timing_val |= hcycle << shift;
+
+ /* no DI input delay first */
+ writel(fread_timing_val, TIMING_REG_AST2600(chip));
+ pass = aspeed_spi_check_reads(chip, golden_buf, test_buf);
+ dev_dbg(aspi->dev,
+ " * [%08x] %d HCLK delay, DI delay none : %s",
+ fread_timing_val, hcycle, pass ? "PASS" : "FAIL");
+ if (pass)
+ return 0;
+
+ /* Add DI input delays */
+ fread_timing_val &= mask;
+ fread_timing_val |= (TIMING_DELAY_DI | hcycle) << shift;
+
+ for (delay_ns = 0; delay_ns < 0x10; delay_ns++) {
+ fread_timing_val &= ~(0xf << (4 + shift));
+ fread_timing_val |= delay_ns << (4 + shift);
+
+ writel(fread_timing_val, TIMING_REG_AST2600(chip));
+ pass = aspeed_spi_check_reads(chip, golden_buf, test_buf);
+ dev_dbg(aspi->dev,
+ " * [%08x] %d HCLK delay, DI delay %d.%dns : %s",
+ fread_timing_val, hcycle, (delay_ns + 1) / 2,
+ (delay_ns + 1) & 1 ? 5 : 5, pass ? "PASS" : "FAIL");
+ /*
+ * TODO: This is optimistic. We should look
+ * for a working interval and save the middle
+ * value in the read timing register.
+ */
+ if (pass)
+ return 0;
+ }
+ }
+
+ /* No good setting for this frequency */
+ return -1;
+}
+
/*
* Platform definitions
*/
@@ -877,6 +1134,10 @@ static const struct aspeed_spi_data ast2400_fmc_data = {
.hastype = true,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
.segment_start = aspeed_spi_segment_start,
.segment_end = aspeed_spi_segment_end,
.segment_reg = aspeed_spi_segment_reg,
@@ -887,6 +1148,10 @@ static const struct aspeed_spi_data ast2400_spi_data = {
.hastype = false,
.we0 = 0,
.ctl0 = 0x04,
+ .timing = 0x14,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
/* No segment registers */
};
@@ -895,6 +1160,10 @@ static const struct aspeed_spi_data ast2500_fmc_data = {
.hastype = true,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
.segment_start = aspeed_spi_segment_start,
.segment_end = aspeed_spi_segment_end,
.segment_reg = aspeed_spi_segment_reg,
@@ -905,6 +1174,10 @@ static const struct aspeed_spi_data ast2500_spi_data = {
.hastype = false,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
.segment_start = aspeed_spi_segment_start,
.segment_end = aspeed_spi_segment_end,
.segment_reg = aspeed_spi_segment_reg,
@@ -916,6 +1189,10 @@ static const struct aspeed_spi_data ast2600_fmc_data = {
.mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xf0fff0ff,
+ .hdiv_max = 2,
+ .calibrate = aspeed_spi_ast2600_calibrate,
.segment_start = aspeed_spi_segment_ast2600_start,
.segment_end = aspeed_spi_segment_ast2600_end,
.segment_reg = aspeed_spi_segment_ast2600_reg,
@@ -927,6 +1204,10 @@ static const struct aspeed_spi_data ast2600_spi_data = {
.mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xf0fff0ff,
+ .hdiv_max = 2,
+ .calibrate = aspeed_spi_ast2600_calibrate,
.segment_start = aspeed_spi_segment_ast2600_start,
.segment_end = aspeed_spi_segment_ast2600_end,
.segment_reg = aspeed_spi_segment_ast2600_reg,
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 08/10] spi: aspeed: Calibrate read timings
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
To accommodate the different response time of SPI transfers on different
boards and different SPI NOR devices, the Aspeed controllers provide a
set of Read Timing Compensation registers to tune the timing delays
depending on the frequency being used. The AST2600 SoC has one of
these registers per device. On the AST2500 and AST2400 SoCs, the
timing register is shared by all devices which is a bit problematic to
get good results other than for one device.
The algorithm first reads a golden buffer at low speed and then performs
reads with different clocks and delay cycle settings to find a breaking
point. This selects a default good frequency for the CEx control register.
The current settings are bit optimistic as we pick the first delay giving
good results. A safer approach would be to determine an interval and
choose the middle value.
Due to the lack of API, calibration is performed when the direct mapping
for reads is created.
Cc: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 281 +++++++++++++++++++++++++++++++++++
1 file changed, 281 insertions(+)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index e44e80bab50f..a08c20308404 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -35,6 +35,8 @@
#define CTRL_IO_ADDRESS_4B BIT(13) /* AST2400 SPI only */
#define CTRL_IO_DUMMY_SET(dummy) \
(((((dummy) >> 2) & 0x1) << 14) | (((dummy) & 0x3) << 6))
+#define CTRL_FREQ_SEL_SHIFT 8
+#define CTRL_FREQ_SEL_MASK GENMASK(11, CTRL_FREQ_SEL_SHIFT)
#define CTRL_CE_STOP_ACTIVE BIT(2)
#define CTRL_IO_MODE_CMD_MASK GENMASK(1, 0)
#define CTRL_IO_MODE_NORMAL 0x0
@@ -47,6 +49,9 @@
/* CEx Address Decoding Range Register */
#define CE0_SEGMENT_ADDR_REG 0x30
+/* CEx Read timing compensation register */
+#define CE0_TIMING_COMPENSATION_REG 0x94
+
enum aspeed_spi_ctl_reg_value {
ASPEED_SPI_BASE,
ASPEED_SPI_READ,
@@ -72,10 +77,15 @@ struct aspeed_spi_data {
bool hastype;
u32 mode_bits;
u32 we0;
+ u32 timing;
+ u32 hclk_mask;
+ u32 hdiv_max;
u32 (*segment_start)(struct aspeed_spi *aspi, u32 reg);
u32 (*segment_end)(struct aspeed_spi *aspi, u32 reg);
u32 (*segment_reg)(struct aspeed_spi *aspi, u32 start, u32 end);
+ int (*calibrate)(struct aspeed_spi_chip *chip, u32 hdiv,
+ const u8 *golden_buf, u8 *test_buf);
};
#define ASPEED_SPI_MAX_NUM_CS 5
@@ -540,6 +550,8 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
return 0;
}
+static int aspeed_spi_do_calibration(struct aspeed_spi_chip *chip);
+
static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
{
struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
@@ -588,6 +600,8 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+ ret = aspeed_spi_do_calibration(chip);
+
dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
@@ -869,6 +883,249 @@ static u32 aspeed_spi_segment_ast2600_reg(struct aspeed_spi *aspi,
((end - 1) & AST2600_SEG_ADDR_MASK);
}
+/*
+ * Read timing compensation sequences
+ */
+
+#define CALIBRATE_BUF_SIZE SZ_16K
+
+static bool aspeed_spi_check_reads(struct aspeed_spi_chip *chip,
+ const u8 *golden_buf, u8 *test_buf)
+{
+ int i;
+
+ for (i = 0; i < 10; i++) {
+ memcpy_fromio(test_buf, chip->ahb_base, CALIBRATE_BUF_SIZE);
+ if (memcmp(test_buf, golden_buf, CALIBRATE_BUF_SIZE) != 0) {
+#if defined(VERBOSE_DEBUG)
+ print_hex_dump_bytes(DEVICE_NAME " fail: ", DUMP_PREFIX_NONE,
+ test_buf, 0x100);
+#endif
+ return false;
+ }
+ }
+ return true;
+}
+
+#define FREAD_TPASS(i) (((i) / 2) | (((i) & 1) ? 0 : 8))
+
+/*
+ * The timing register is shared by all devices. Only update for CE0.
+ */
+static int aspeed_spi_calibrate(struct aspeed_spi_chip *chip, u32 hdiv,
+ const u8 *golden_buf, u8 *test_buf)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ const struct aspeed_spi_data *data = aspi->data;
+ int i;
+ int good_pass = -1, pass_count = 0;
+ u32 shift = (hdiv - 1) << 2;
+ u32 mask = ~(0xfu << shift);
+ u32 fread_timing_val = 0;
+
+ /* Try HCLK delay 0..5, each one with/without delay and look for a
+ * good pair.
+ */
+ for (i = 0; i < 12; i++) {
+ bool pass;
+
+ if (chip->cs == 0) {
+ fread_timing_val &= mask;
+ fread_timing_val |= FREAD_TPASS(i) << shift;
+ writel(fread_timing_val, aspi->regs + data->timing);
+ }
+ pass = aspeed_spi_check_reads(chip, golden_buf, test_buf);
+ dev_dbg(aspi->dev,
+ " * [%08x] %d HCLK delay, %dns DI delay : %s",
+ fread_timing_val, i / 2, (i & 1) ? 0 : 4,
+ pass ? "PASS" : "FAIL");
+ if (pass) {
+ pass_count++;
+ if (pass_count == 3) {
+ good_pass = i - 1;
+ break;
+ }
+ } else {
+ pass_count = 0;
+ }
+ }
+
+ /* No good setting for this frequency */
+ if (good_pass < 0)
+ return -1;
+
+ /* We have at least one pass of margin, let's use first pass */
+ if (chip->cs == 0) {
+ fread_timing_val &= mask;
+ fread_timing_val |= FREAD_TPASS(good_pass) << shift;
+ writel(fread_timing_val, aspi->regs + data->timing);
+ }
+ dev_dbg(aspi->dev, " * -> good is pass %d [0x%08x]",
+ good_pass, fread_timing_val);
+ return 0;
+}
+
+static bool aspeed_spi_check_calib_data(const u8 *test_buf, u32 size)
+{
+ const u32 *tb32 = (const u32 *)test_buf;
+ u32 i, cnt = 0;
+
+ /* We check if we have enough words that are neither all 0
+ * nor all 1's so the calibration can be considered valid.
+ *
+ * I use an arbitrary threshold for now of 64
+ */
+ size >>= 2;
+ for (i = 0; i < size; i++) {
+ if (tb32[i] != 0 && tb32[i] != 0xffffffff)
+ cnt++;
+ }
+ return cnt >= 64;
+}
+
+static const u32 aspeed_spi_hclk_divs[] = {
+ 0xf, /* HCLK */
+ 0x7, /* HCLK/2 */
+ 0xe, /* HCLK/3 */
+ 0x6, /* HCLK/4 */
+ 0xd, /* HCLK/5 */
+};
+
+#define ASPEED_SPI_HCLK_DIV(i) \
+ (aspeed_spi_hclk_divs[(i) - 1] << CTRL_FREQ_SEL_SHIFT)
+
+static int aspeed_spi_do_calibration(struct aspeed_spi_chip *chip)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ const struct aspeed_spi_data *data = aspi->data;
+ u32 ahb_freq = aspi->clk_freq;
+ u32 max_freq = chip->clk_freq;
+ u32 ctl_val;
+ u8 *golden_buf = NULL;
+ u8 *test_buf = NULL;
+ int i, rc, best_div = -1;
+
+ dev_dbg(aspi->dev, "calculate timing compensation - AHB freq: %d MHz",
+ ahb_freq / 1000000);
+
+ /*
+ * use the related low frequency to get check calibration data
+ * and get golden data.
+ */
+ ctl_val = chip->ctl_val[ASPEED_SPI_READ] & data->hclk_mask;
+ writel(ctl_val, chip->ctl);
+
+ test_buf = kzalloc(CALIBRATE_BUF_SIZE * 2, GFP_KERNEL);
+ if (!test_buf)
+ return -ENOMEM;
+
+ golden_buf = test_buf + CALIBRATE_BUF_SIZE;
+
+ memcpy_fromio(golden_buf, chip->ahb_base, CALIBRATE_BUF_SIZE);
+ if (!aspeed_spi_check_calib_data(golden_buf, CALIBRATE_BUF_SIZE)) {
+ dev_info(aspi->dev, "Calibration area too uniform, using low speed");
+ goto no_calib;
+ }
+
+#if defined(VERBOSE_DEBUG)
+ print_hex_dump_bytes(DEVICE_NAME " good: ", DUMP_PREFIX_NONE,
+ golden_buf, 0x100);
+#endif
+
+ /* Now we iterate the HCLK dividers until we find our breaking point */
+ for (i = ARRAY_SIZE(aspeed_spi_hclk_divs); i > data->hdiv_max - 1; i--) {
+ u32 tv, freq;
+
+ freq = ahb_freq / i;
+ if (freq > max_freq)
+ continue;
+
+ /* Set the timing */
+ tv = chip->ctl_val[ASPEED_SPI_READ] | ASPEED_SPI_HCLK_DIV(i);
+ writel(tv, chip->ctl);
+ dev_dbg(aspi->dev, "Trying HCLK/%d [%08x] ...", i, tv);
+ rc = data->calibrate(chip, i, golden_buf, test_buf);
+ if (rc == 0)
+ best_div = i;
+ }
+
+ /* Nothing found ? */
+ if (best_div < 0) {
+ dev_warn(aspi->dev, "No good frequency, using dumb slow");
+ } else {
+ dev_dbg(aspi->dev, "Found good read timings at HCLK/%d", best_div);
+
+ /* Record the freq */
+ for (i = 0; i < ASPEED_SPI_MAX; i++)
+ chip->ctl_val[i] = (chip->ctl_val[i] & data->hclk_mask) |
+ ASPEED_SPI_HCLK_DIV(best_div);
+ }
+
+no_calib:
+ writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
+ kfree(test_buf);
+ return 0;
+}
+
+#define TIMING_DELAY_DI BIT(3)
+#define TIMING_DELAY_HCYCLE_MAX 5
+#define TIMING_REG_AST2600(chip) \
+ ((chip)->aspi->regs + (chip)->aspi->data->timing + \
+ (chip)->cs * 4)
+
+static int aspeed_spi_ast2600_calibrate(struct aspeed_spi_chip *chip, u32 hdiv,
+ const u8 *golden_buf, u8 *test_buf)
+{
+ struct aspeed_spi *aspi = chip->aspi;
+ int hcycle;
+ u32 shift = (hdiv - 2) << 3;
+ u32 mask = ~(0xfu << shift);
+ u32 fread_timing_val = 0;
+
+ for (hcycle = 0; hcycle <= TIMING_DELAY_HCYCLE_MAX; hcycle++) {
+ int delay_ns;
+ bool pass = false;
+
+ fread_timing_val &= mask;
+ fread_timing_val |= hcycle << shift;
+
+ /* no DI input delay first */
+ writel(fread_timing_val, TIMING_REG_AST2600(chip));
+ pass = aspeed_spi_check_reads(chip, golden_buf, test_buf);
+ dev_dbg(aspi->dev,
+ " * [%08x] %d HCLK delay, DI delay none : %s",
+ fread_timing_val, hcycle, pass ? "PASS" : "FAIL");
+ if (pass)
+ return 0;
+
+ /* Add DI input delays */
+ fread_timing_val &= mask;
+ fread_timing_val |= (TIMING_DELAY_DI | hcycle) << shift;
+
+ for (delay_ns = 0; delay_ns < 0x10; delay_ns++) {
+ fread_timing_val &= ~(0xf << (4 + shift));
+ fread_timing_val |= delay_ns << (4 + shift);
+
+ writel(fread_timing_val, TIMING_REG_AST2600(chip));
+ pass = aspeed_spi_check_reads(chip, golden_buf, test_buf);
+ dev_dbg(aspi->dev,
+ " * [%08x] %d HCLK delay, DI delay %d.%dns : %s",
+ fread_timing_val, hcycle, (delay_ns + 1) / 2,
+ (delay_ns + 1) & 1 ? 5 : 5, pass ? "PASS" : "FAIL");
+ /*
+ * TODO: This is optimistic. We should look
+ * for a working interval and save the middle
+ * value in the read timing register.
+ */
+ if (pass)
+ return 0;
+ }
+ }
+
+ /* No good setting for this frequency */
+ return -1;
+}
+
/*
* Platform definitions
*/
@@ -877,6 +1134,10 @@ static const struct aspeed_spi_data ast2400_fmc_data = {
.hastype = true,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
.segment_start = aspeed_spi_segment_start,
.segment_end = aspeed_spi_segment_end,
.segment_reg = aspeed_spi_segment_reg,
@@ -887,6 +1148,10 @@ static const struct aspeed_spi_data ast2400_spi_data = {
.hastype = false,
.we0 = 0,
.ctl0 = 0x04,
+ .timing = 0x14,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
/* No segment registers */
};
@@ -895,6 +1160,10 @@ static const struct aspeed_spi_data ast2500_fmc_data = {
.hastype = true,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
.segment_start = aspeed_spi_segment_start,
.segment_end = aspeed_spi_segment_end,
.segment_reg = aspeed_spi_segment_reg,
@@ -905,6 +1174,10 @@ static const struct aspeed_spi_data ast2500_spi_data = {
.hastype = false,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xfffff0ff,
+ .hdiv_max = 1,
+ .calibrate = aspeed_spi_calibrate,
.segment_start = aspeed_spi_segment_start,
.segment_end = aspeed_spi_segment_end,
.segment_reg = aspeed_spi_segment_reg,
@@ -916,6 +1189,10 @@ static const struct aspeed_spi_data ast2600_fmc_data = {
.mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xf0fff0ff,
+ .hdiv_max = 2,
+ .calibrate = aspeed_spi_ast2600_calibrate,
.segment_start = aspeed_spi_segment_ast2600_start,
.segment_end = aspeed_spi_segment_ast2600_end,
.segment_reg = aspeed_spi_segment_ast2600_reg,
@@ -927,6 +1204,10 @@ static const struct aspeed_spi_data ast2600_spi_data = {
.mode_bits = SPI_RX_QUAD | SPI_RX_QUAD,
.we0 = 16,
.ctl0 = CE0_CTRL_REG,
+ .timing = CE0_TIMING_COMPENSATION_REG,
+ .hclk_mask = 0xf0fff0ff,
+ .hdiv_max = 2,
+ .calibrate = aspeed_spi_ast2600_calibrate,
.segment_start = aspeed_spi_segment_ast2600_start,
.segment_end = aspeed_spi_segment_ast2600_end,
.segment_reg = aspeed_spi_segment_ast2600_reg,
--
2.34.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] 115+ messages in thread
* [PATCH 09/10] ARM: dts: aspeed: Enable Dual SPI RX transfers
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
All these controllers support at least Dual SPI. Update the DTs.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 6 ++++++
arch/arm/boot/dts/aspeed-g5.dtsi | 7 +++++++
arch/arm/boot/dts/aspeed-g6.dtsi | 8 ++++++++
3 files changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index f14dace34c5a..da211fbd8658 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -65,27 +65,32 @@ fmc: spi@1e620000 {
flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
spi-max-frequency = <50000000>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@3 {
reg = < 3 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@4 {
reg = < 4 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -102,6 +107,7 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 7495f93c5069..804b66d32127 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -67,18 +67,21 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -95,12 +98,14 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -117,12 +122,14 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index c32e87fad4dc..542714c61a85 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -107,18 +107,21 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -135,12 +138,14 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -157,18 +162,21 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 09/10] ARM: dts: aspeed: Enable Dual SPI RX transfers
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
All these controllers support at least Dual SPI. Update the DTs.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 6 ++++++
arch/arm/boot/dts/aspeed-g5.dtsi | 7 +++++++
arch/arm/boot/dts/aspeed-g6.dtsi | 8 ++++++++
3 files changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index f14dace34c5a..da211fbd8658 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -65,27 +65,32 @@ fmc: spi@1e620000 {
flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
spi-max-frequency = <50000000>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@3 {
reg = < 3 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@4 {
reg = < 4 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -102,6 +107,7 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 7495f93c5069..804b66d32127 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -67,18 +67,21 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -95,12 +98,14 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -117,12 +122,14 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index c32e87fad4dc..542714c61a85 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -107,18 +107,21 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -135,12 +138,14 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -157,18 +162,21 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 09/10] ARM: dts: aspeed: Enable Dual SPI RX transfers
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
All these controllers support at least Dual SPI. Update the DTs.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 6 ++++++
arch/arm/boot/dts/aspeed-g5.dtsi | 7 +++++++
arch/arm/boot/dts/aspeed-g6.dtsi | 8 ++++++++
3 files changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index f14dace34c5a..da211fbd8658 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -65,27 +65,32 @@ fmc: spi@1e620000 {
flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
spi-max-frequency = <50000000>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@3 {
reg = < 3 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@4 {
reg = < 4 >;
compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -102,6 +107,7 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 7495f93c5069..804b66d32127 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -67,18 +67,21 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -95,12 +98,14 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -117,12 +122,14 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index c32e87fad4dc..542714c61a85 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -107,18 +107,21 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -135,12 +138,14 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
@@ -157,18 +162,21 @@ flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
status = "disabled";
};
};
--
2.34.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] 115+ messages in thread
* [PATCH 10/10] spi: aspeed: Activate new spi-mem driver
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-14 9:42 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
The previous driver using the MTD SPI NOR interface is kept in case we
find some issues but we should remove it quickly once the new driver
using the spi-mem interface has been sufficiently exposed.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/configs/aspeed_g4_defconfig | 2 +-
arch/arm/configs/aspeed_g5_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/multi_v7_defconfig | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index 964536444cd7..b4a1b2ed1a17 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index e809236ca88b..ccc4240ee4b5 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index 49083ef05fb0..80a3ae02d759 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_ORION=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=y
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_ATMEL_SSC=m
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index fc1b69256b64..33572998dbbe 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_NAND_STM32_FMC2=y
CONFIG_MTD_NAND_PL35X=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
+CONFIG_SPI_ASPEED_SMC=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
--
2.34.1
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 10/10] spi: aspeed: Activate new spi-mem driver
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
The previous driver using the MTD SPI NOR interface is kept in case we
find some issues but we should remove it quickly once the new driver
using the spi-mem interface has been sufficiently exposed.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/configs/aspeed_g4_defconfig | 2 +-
arch/arm/configs/aspeed_g5_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/multi_v7_defconfig | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index 964536444cd7..b4a1b2ed1a17 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index e809236ca88b..ccc4240ee4b5 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index 49083ef05fb0..80a3ae02d759 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_ORION=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=y
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_ATMEL_SSC=m
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index fc1b69256b64..33572998dbbe 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_NAND_STM32_FMC2=y
CONFIG_MTD_NAND_PL35X=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
+CONFIG_SPI_ASPEED_SMC=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 10/10] spi: aspeed: Activate new spi-mem driver
@ 2022-02-14 9:42 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-14 9:42 UTC (permalink / raw)
To: linux-spi, linux-mtd
Cc: Mark Brown, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel,
Cédric Le Goater
The previous driver using the MTD SPI NOR interface is kept in case we
find some issues but we should remove it quickly once the new driver
using the spi-mem interface has been sufficiently exposed.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/configs/aspeed_g4_defconfig | 2 +-
arch/arm/configs/aspeed_g5_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/multi_v7_defconfig | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index 964536444cd7..b4a1b2ed1a17 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index e809236ca88b..ccc4240ee4b5 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_PARTITIONED_MASTER=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y
diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index 49083ef05fb0..80a3ae02d759 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_ORION=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
+CONFIG_SPI_ASPEED_SMC=y
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_ATMEL_SSC=m
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index fc1b69256b64..33572998dbbe 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_NAND_STM32_FMC2=y
CONFIG_MTD_NAND_PL35X=y
CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
+CONFIG_SPI_ASPEED_SMC=m
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
--
2.34.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] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
2022-02-14 9:42 ` Cédric Le Goater
(?)
(?)
@ 2022-02-15 6:27 ` Lukas Wunner
2022-02-15 9:07 ` Cédric Le Goater
-1 siblings, 1 reply; 115+ messages in thread
From: Lukas Wunner @ 2022-02-15 6:27 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, Rob Herring, linux-arm-kernel, linux-kernel
On Mon, Feb 14, 2022 at 10:42:24AM +0100, Cédric Le Goater wrote:
> +static int aspeed_spi_probe(struct platform_device *pdev)
> +{
[...]
> + ctlr = spi_alloc_master(dev, sizeof(*aspi));
> + if (!ctlr)
> + return -ENOMEM;
Use devm_spi_alloc_master() and remove the "put_controller" error path
for simplicity.
> + ret = devm_spi_register_controller(dev, ctlr);
[...]
> +static int aspeed_spi_remove(struct platform_device *pdev)
> +{
> + struct spi_controller *ctlr = platform_get_drvdata(pdev);
> + struct aspeed_spi *aspi = spi_controller_get_devdata(ctlr);
> +
> + aspeed_spi_enable(aspi, false);
> + spi_unregister_controller(ctlr);
> + clk_disable_unprepare(aspi->clk);
> + return 0;
> +}
You need to move the call to spi_unregister_controller() *before*
the call to aspeed_spi_enable(). The controller must be fully
operational until spi_unregister_controller() returns.
You also need to replace the call to devm_spi_register_controller()
in aspeed_spi_probe() with spi_register_controller().
Otherwise you'll unregister the controller twice because you're
calling spi_unregister_controller() in aspeed_spi_remove().
Thanks,
Lukas
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
2022-02-15 6:27 ` Lukas Wunner
2022-02-15 9:07 ` Cédric Le Goater
@ 2022-02-15 9:07 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-15 9:07 UTC (permalink / raw)
To: Lukas Wunner
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, Rob Herring, linux-arm-kernel, linux-kernel
Hello Lukas,
On 2/15/22 07:27, Lukas Wunner wrote:
> On Mon, Feb 14, 2022 at 10:42:24AM +0100, Cédric Le Goater wrote:
>> +static int aspeed_spi_probe(struct platform_device *pdev)
>> +{
> [...]
>> + ctlr = spi_alloc_master(dev, sizeof(*aspi));
>> + if (!ctlr)
>> + return -ENOMEM;
>
> Use devm_spi_alloc_master() and remove the "put_controller" error path
> for simplicity.
yes.
>> + ret = devm_spi_register_controller(dev, ctlr);
> [...]
>> +static int aspeed_spi_remove(struct platform_device *pdev)
>> +{
>> + struct spi_controller *ctlr = platform_get_drvdata(pdev);
>> + struct aspeed_spi *aspi = spi_controller_get_devdata(ctlr);
>> +
>> + aspeed_spi_enable(aspi, false);
>> + spi_unregister_controller(ctlr);
>> + clk_disable_unprepare(aspi->clk);
>> + return 0;
>> +}
>
> You need to move the call to spi_unregister_controller() *before*
> the call to aspeed_spi_enable(). The controller must be fully
> operational until spi_unregister_controller() returns.
>
> You also need to replace the call to devm_spi_register_controller()
> in aspeed_spi_probe() with spi_register_controller().
> Otherwise you'll unregister the controller twice because you're
> calling spi_unregister_controller() in aspeed_spi_remove().
ok. Understood. Done in v2.
Thanks,
C.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-15 9:07 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-15 9:07 UTC (permalink / raw)
To: Lukas Wunner
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, Rob Herring, linux-arm-kernel, linux-kernel
Hello Lukas,
On 2/15/22 07:27, Lukas Wunner wrote:
> On Mon, Feb 14, 2022 at 10:42:24AM +0100, Cédric Le Goater wrote:
>> +static int aspeed_spi_probe(struct platform_device *pdev)
>> +{
> [...]
>> + ctlr = spi_alloc_master(dev, sizeof(*aspi));
>> + if (!ctlr)
>> + return -ENOMEM;
>
> Use devm_spi_alloc_master() and remove the "put_controller" error path
> for simplicity.
yes.
>> + ret = devm_spi_register_controller(dev, ctlr);
> [...]
>> +static int aspeed_spi_remove(struct platform_device *pdev)
>> +{
>> + struct spi_controller *ctlr = platform_get_drvdata(pdev);
>> + struct aspeed_spi *aspi = spi_controller_get_devdata(ctlr);
>> +
>> + aspeed_spi_enable(aspi, false);
>> + spi_unregister_controller(ctlr);
>> + clk_disable_unprepare(aspi->clk);
>> + return 0;
>> +}
>
> You need to move the call to spi_unregister_controller() *before*
> the call to aspeed_spi_enable(). The controller must be fully
> operational until spi_unregister_controller() returns.
>
> You also need to replace the call to devm_spi_register_controller()
> in aspeed_spi_probe() with spi_register_controller().
> Otherwise you'll unregister the controller twice because you're
> calling spi_unregister_controller() in aspeed_spi_remove().
ok. Understood. Done in v2.
Thanks,
C.
_______________________________________________
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] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-15 9:07 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-15 9:07 UTC (permalink / raw)
To: Lukas Wunner
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, Rob Herring, linux-arm-kernel, linux-kernel
Hello Lukas,
On 2/15/22 07:27, Lukas Wunner wrote:
> On Mon, Feb 14, 2022 at 10:42:24AM +0100, Cédric Le Goater wrote:
>> +static int aspeed_spi_probe(struct platform_device *pdev)
>> +{
> [...]
>> + ctlr = spi_alloc_master(dev, sizeof(*aspi));
>> + if (!ctlr)
>> + return -ENOMEM;
>
> Use devm_spi_alloc_master() and remove the "put_controller" error path
> for simplicity.
yes.
>> + ret = devm_spi_register_controller(dev, ctlr);
> [...]
>> +static int aspeed_spi_remove(struct platform_device *pdev)
>> +{
>> + struct spi_controller *ctlr = platform_get_drvdata(pdev);
>> + struct aspeed_spi *aspi = spi_controller_get_devdata(ctlr);
>> +
>> + aspeed_spi_enable(aspi, false);
>> + spi_unregister_controller(ctlr);
>> + clk_disable_unprepare(aspi->clk);
>> + return 0;
>> +}
>
> You need to move the call to spi_unregister_controller() *before*
> the call to aspeed_spi_enable(). The controller must be fully
> operational until spi_unregister_controller() returns.
>
> You also need to replace the call to devm_spi_register_controller()
> in aspeed_spi_probe() with spi_register_controller().
> Otherwise you'll unregister the controller twice because you're
> calling spi_unregister_controller() in aspeed_spi_remove().
ok. Understood. Done in v2.
Thanks,
C.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-15 19:49 ` Rob Herring
-1 siblings, 0 replies; 115+ messages in thread
From: Rob Herring @ 2022-02-15 19:49 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-aspeed, Richard Weinberger, linux-spi, linux-mtd,
Mark Brown, Rob Herring, linux-arm-kernel, Andrew Jeffery,
Pratyush Yadav, Chin-Ting Kuo, linux-kernel, Joel Stanley,
Tudor Ambarus, Miquel Raynal, Vignesh Raghavendra, devicetree
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]
On Mon, 14 Feb 2022 10:42:23 +0100, Cédric Le Goater wrote:
> The "interrupt" property is optional because it is only necessary for
> controllers supporting DMAs (Not implemented yet in the new driver).
>
> Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.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:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.example.dt.yaml: example-0: spi@1e620000:reg:0: [509739008, 196, 536870912, 268435456] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.example.dt.yaml: spi@1e620000: reg: [[509739008, 196, 536870912, 268435456]] is too short
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1592369
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.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
@ 2022-02-15 19:49 ` Rob Herring
0 siblings, 0 replies; 115+ messages in thread
From: Rob Herring @ 2022-02-15 19:49 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-aspeed, Richard Weinberger, linux-spi, linux-mtd,
Mark Brown, Rob Herring, linux-arm-kernel, Andrew Jeffery,
Pratyush Yadav, Chin-Ting Kuo, linux-kernel, Joel Stanley,
Tudor Ambarus, Miquel Raynal, Vignesh Raghavendra, devicetree
[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]
On Mon, 14 Feb 2022 10:42:23 +0100, Cédric Le Goater wrote:
> The "interrupt" property is optional because it is only necessary for
> controllers supporting DMAs (Not implemented yet in the new driver).
>
> Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.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:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.example.dt.yaml: example-0: spi@1e620000:reg:0: [509739008, 196, 536870912, 268435456] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.example.dt.yaml: spi@1e620000: reg: [[509739008, 196, 536870912, 268435456]] is too short
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1592369
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.
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
@ 2022-02-15 19:49 ` Rob Herring
0 siblings, 0 replies; 115+ messages in thread
From: Rob Herring @ 2022-02-15 19:49 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-aspeed, Richard Weinberger, linux-spi, linux-mtd,
Mark Brown, Rob Herring, linux-arm-kernel, Andrew Jeffery,
Pratyush Yadav, Chin-Ting Kuo, linux-kernel, Joel Stanley,
Tudor Ambarus, Miquel Raynal, Vignesh Raghavendra, devicetree
[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]
On Mon, 14 Feb 2022 10:42:23 +0100, Cédric Le Goater wrote:
> The "interrupt" property is optional because it is only necessary for
> controllers supporting DMAs (Not implemented yet in the new driver).
>
> Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.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:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.example.dt.yaml: example-0: spi@1e620000:reg:0: [509739008, 196, 536870912, 268435456] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.example.dt.yaml: spi@1e620000: reg: [[509739008, 196, 536870912, 268435456]] is too short
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1592369
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.
[-- 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] 115+ messages in thread
* Re: [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-15 21:06 ` Rob Herring
-1 siblings, 0 replies; 115+ messages in thread
From: Rob Herring @ 2022-02-15 21:06 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, linux-arm-kernel, linux-kernel
On Mon, Feb 14, 2022 at 10:42:23AM +0100, Cédric Le Goater wrote:
> The "interrupt" property is optional because it is only necessary for
> controllers supporting DMAs (Not implemented yet in the new driver).
>
> Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> new file mode 100644
> index 000000000000..ed71c4d86930
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> @@ -0,0 +1,92 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed SMC controllers bindings
> +
> +maintainers:
> + - Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> + - Cédric Le Goater <clg@kaod.org>
> +
> +description: |
> + This binding describes the Aspeed Static Memory Controllers (FMC and
> + SPI) of the AST2400, AST2500 and AST2600 SOCs.
> +
> +allOf:
> + - $ref: "spi-controller.yaml#"
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2600-fmc
> + - aspeed,ast2600-spi
> + - aspeed,ast2500-fmc
> + - aspeed,ast2500-spi
> + - aspeed,ast2400-fmc
> + - aspeed,ast2400-spi
> +
> + reg:
> + items:
> + - description: registers
> + - description: memory mapping
> +
> + clocks:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> +patternProperties:
> + "@[0-9a-f]+":
> + type: object
> +
> + properties:
> + spi-rx-bus-width:
> + enum: [1, 2, 4]
> +
> + required:
> + - reg
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
> + #include <dt-bindings/clock/ast2600-clock.h>
> +
> + spi@1e620000 {
> + reg = < 0x1e620000 0xc4
> + 0x20000000 0x10000000 >;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "aspeed,ast2600-fmc";
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + status = "disabled";
Why is your example disabled? Drop 'status'.
> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> + flash@0 {
> + reg = < 0 >;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
Ditto.
> + };
> + flash@1 {
> + reg = < 1 >;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> + flash@2 {
> + reg = < 2 >;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> + };
> --
> 2.34.1
>
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
@ 2022-02-15 21:06 ` Rob Herring
0 siblings, 0 replies; 115+ messages in thread
From: Rob Herring @ 2022-02-15 21:06 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, linux-arm-kernel, linux-kernel
On Mon, Feb 14, 2022 at 10:42:23AM +0100, Cédric Le Goater wrote:
> The "interrupt" property is optional because it is only necessary for
> controllers supporting DMAs (Not implemented yet in the new driver).
>
> Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> new file mode 100644
> index 000000000000..ed71c4d86930
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> @@ -0,0 +1,92 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed SMC controllers bindings
> +
> +maintainers:
> + - Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> + - Cédric Le Goater <clg@kaod.org>
> +
> +description: |
> + This binding describes the Aspeed Static Memory Controllers (FMC and
> + SPI) of the AST2400, AST2500 and AST2600 SOCs.
> +
> +allOf:
> + - $ref: "spi-controller.yaml#"
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2600-fmc
> + - aspeed,ast2600-spi
> + - aspeed,ast2500-fmc
> + - aspeed,ast2500-spi
> + - aspeed,ast2400-fmc
> + - aspeed,ast2400-spi
> +
> + reg:
> + items:
> + - description: registers
> + - description: memory mapping
> +
> + clocks:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> +patternProperties:
> + "@[0-9a-f]+":
> + type: object
> +
> + properties:
> + spi-rx-bus-width:
> + enum: [1, 2, 4]
> +
> + required:
> + - reg
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
> + #include <dt-bindings/clock/ast2600-clock.h>
> +
> + spi@1e620000 {
> + reg = < 0x1e620000 0xc4
> + 0x20000000 0x10000000 >;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "aspeed,ast2600-fmc";
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + status = "disabled";
Why is your example disabled? Drop 'status'.
> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> + flash@0 {
> + reg = < 0 >;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
Ditto.
> + };
> + flash@1 {
> + reg = < 1 >;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> + flash@2 {
> + reg = < 2 >;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> + };
> --
> 2.34.1
>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
@ 2022-02-15 21:06 ` Rob Herring
0 siblings, 0 replies; 115+ messages in thread
From: Rob Herring @ 2022-02-15 21:06 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, linux-arm-kernel, linux-kernel
On Mon, Feb 14, 2022 at 10:42:23AM +0100, Cédric Le Goater wrote:
> The "interrupt" property is optional because it is only necessary for
> controllers supporting DMAs (Not implemented yet in the new driver).
>
> Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> new file mode 100644
> index 000000000000..ed71c4d86930
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> @@ -0,0 +1,92 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed SMC controllers bindings
> +
> +maintainers:
> + - Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> + - Cédric Le Goater <clg@kaod.org>
> +
> +description: |
> + This binding describes the Aspeed Static Memory Controllers (FMC and
> + SPI) of the AST2400, AST2500 and AST2600 SOCs.
> +
> +allOf:
> + - $ref: "spi-controller.yaml#"
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2600-fmc
> + - aspeed,ast2600-spi
> + - aspeed,ast2500-fmc
> + - aspeed,ast2500-spi
> + - aspeed,ast2400-fmc
> + - aspeed,ast2400-spi
> +
> + reg:
> + items:
> + - description: registers
> + - description: memory mapping
> +
> + clocks:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> +patternProperties:
> + "@[0-9a-f]+":
> + type: object
> +
> + properties:
> + spi-rx-bus-width:
> + enum: [1, 2, 4]
> +
> + required:
> + - reg
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
> + #include <dt-bindings/clock/ast2600-clock.h>
> +
> + spi@1e620000 {
> + reg = < 0x1e620000 0xc4
> + 0x20000000 0x10000000 >;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "aspeed,ast2600-fmc";
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + status = "disabled";
Why is your example disabled? Drop 'status'.
> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> + flash@0 {
> + reg = < 0 >;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
Ditto.
> + };
> + flash@1 {
> + reg = < 1 >;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> + flash@2 {
> + reg = < 2 >;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> + };
> --
> 2.34.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] 115+ messages in thread
* Re: [PATCH 10/10] spi: aspeed: Activate new spi-mem driver
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-16 7:02 ` Joel Stanley
-1 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-16 7:02 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Mon, 14 Feb 2022 at 09:43, Cédric Le Goater <clg@kaod.org> wrote:
>
> The previous driver using the MTD SPI NOR interface is kept in case we
> find some issues but we should remove it quickly once the new driver
> using the spi-mem interface has been sufficiently exposed.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
I suggest we drop the defconfig changes from both this patch and the
first. This way we'll always have the new driver being built, with
less churn.
If you strongly prefer the way you've done it then that's fine too.
> ---
> arch/arm/configs/aspeed_g4_defconfig | 2 +-
> arch/arm/configs/aspeed_g5_defconfig | 2 +-
> arch/arm/configs/multi_v5_defconfig | 2 +-
> arch/arm/configs/multi_v7_defconfig | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
> index 964536444cd7..b4a1b2ed1a17 100644
> --- a/arch/arm/configs/aspeed_g4_defconfig
> +++ b/arch/arm/configs/aspeed_g4_defconfig
> @@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
> CONFIG_MTD_PARTITIONED_MASTER=y
> CONFIG_MTD_SPI_NOR=y
> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
> +CONFIG_SPI_ASPEED_SMC=y
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_FASTMAP=y
> CONFIG_MTD_UBI_BLOCK=y
> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
> index e809236ca88b..ccc4240ee4b5 100644
> --- a/arch/arm/configs/aspeed_g5_defconfig
> +++ b/arch/arm/configs/aspeed_g5_defconfig
> @@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
> CONFIG_MTD_PARTITIONED_MASTER=y
> CONFIG_MTD_SPI_NOR=y
> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
> +CONFIG_SPI_ASPEED_SMC=y
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_FASTMAP=y
> CONFIG_MTD_UBI_BLOCK=y
> diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
> index 49083ef05fb0..80a3ae02d759 100644
> --- a/arch/arm/configs/multi_v5_defconfig
> +++ b/arch/arm/configs/multi_v5_defconfig
> @@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
> CONFIG_MTD_NAND_ATMEL=y
> CONFIG_MTD_NAND_ORION=y
> CONFIG_MTD_SPI_NOR=y
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
> +CONFIG_SPI_ASPEED_SMC=y
> CONFIG_MTD_UBI=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_ATMEL_SSC=m
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index fc1b69256b64..33572998dbbe 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
> CONFIG_MTD_NAND_STM32_FMC2=y
> CONFIG_MTD_NAND_PL35X=y
> CONFIG_MTD_SPI_NOR=y
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
> +CONFIG_SPI_ASPEED_SMC=m
> CONFIG_MTD_UBI=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_RAM=y
> --
> 2.34.1
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 10/10] spi: aspeed: Activate new spi-mem driver
@ 2022-02-16 7:02 ` Joel Stanley
0 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-16 7:02 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Mon, 14 Feb 2022 at 09:43, Cédric Le Goater <clg@kaod.org> wrote:
>
> The previous driver using the MTD SPI NOR interface is kept in case we
> find some issues but we should remove it quickly once the new driver
> using the spi-mem interface has been sufficiently exposed.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
I suggest we drop the defconfig changes from both this patch and the
first. This way we'll always have the new driver being built, with
less churn.
If you strongly prefer the way you've done it then that's fine too.
> ---
> arch/arm/configs/aspeed_g4_defconfig | 2 +-
> arch/arm/configs/aspeed_g5_defconfig | 2 +-
> arch/arm/configs/multi_v5_defconfig | 2 +-
> arch/arm/configs/multi_v7_defconfig | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
> index 964536444cd7..b4a1b2ed1a17 100644
> --- a/arch/arm/configs/aspeed_g4_defconfig
> +++ b/arch/arm/configs/aspeed_g4_defconfig
> @@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
> CONFIG_MTD_PARTITIONED_MASTER=y
> CONFIG_MTD_SPI_NOR=y
> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
> +CONFIG_SPI_ASPEED_SMC=y
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_FASTMAP=y
> CONFIG_MTD_UBI_BLOCK=y
> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
> index e809236ca88b..ccc4240ee4b5 100644
> --- a/arch/arm/configs/aspeed_g5_defconfig
> +++ b/arch/arm/configs/aspeed_g5_defconfig
> @@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
> CONFIG_MTD_PARTITIONED_MASTER=y
> CONFIG_MTD_SPI_NOR=y
> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
> +CONFIG_SPI_ASPEED_SMC=y
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_FASTMAP=y
> CONFIG_MTD_UBI_BLOCK=y
> diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
> index 49083ef05fb0..80a3ae02d759 100644
> --- a/arch/arm/configs/multi_v5_defconfig
> +++ b/arch/arm/configs/multi_v5_defconfig
> @@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
> CONFIG_MTD_NAND_ATMEL=y
> CONFIG_MTD_NAND_ORION=y
> CONFIG_MTD_SPI_NOR=y
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
> +CONFIG_SPI_ASPEED_SMC=y
> CONFIG_MTD_UBI=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_ATMEL_SSC=m
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index fc1b69256b64..33572998dbbe 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
> CONFIG_MTD_NAND_STM32_FMC2=y
> CONFIG_MTD_NAND_PL35X=y
> CONFIG_MTD_SPI_NOR=y
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
> +CONFIG_SPI_ASPEED_SMC=m
> CONFIG_MTD_UBI=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_RAM=y
> --
> 2.34.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] 115+ messages in thread
* Re: [PATCH 10/10] spi: aspeed: Activate new spi-mem driver
@ 2022-02-16 7:02 ` Joel Stanley
0 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-16 7:02 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Mon, 14 Feb 2022 at 09:43, Cédric Le Goater <clg@kaod.org> wrote:
>
> The previous driver using the MTD SPI NOR interface is kept in case we
> find some issues but we should remove it quickly once the new driver
> using the spi-mem interface has been sufficiently exposed.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
I suggest we drop the defconfig changes from both this patch and the
first. This way we'll always have the new driver being built, with
less churn.
If you strongly prefer the way you've done it then that's fine too.
> ---
> arch/arm/configs/aspeed_g4_defconfig | 2 +-
> arch/arm/configs/aspeed_g5_defconfig | 2 +-
> arch/arm/configs/multi_v5_defconfig | 2 +-
> arch/arm/configs/multi_v7_defconfig | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
> index 964536444cd7..b4a1b2ed1a17 100644
> --- a/arch/arm/configs/aspeed_g4_defconfig
> +++ b/arch/arm/configs/aspeed_g4_defconfig
> @@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
> CONFIG_MTD_PARTITIONED_MASTER=y
> CONFIG_MTD_SPI_NOR=y
> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
> +CONFIG_SPI_ASPEED_SMC=y
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_FASTMAP=y
> CONFIG_MTD_UBI_BLOCK=y
> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
> index e809236ca88b..ccc4240ee4b5 100644
> --- a/arch/arm/configs/aspeed_g5_defconfig
> +++ b/arch/arm/configs/aspeed_g5_defconfig
> @@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
> CONFIG_MTD_PARTITIONED_MASTER=y
> CONFIG_MTD_SPI_NOR=y
> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
> +CONFIG_SPI_ASPEED_SMC=y
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_FASTMAP=y
> CONFIG_MTD_UBI_BLOCK=y
> diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
> index 49083ef05fb0..80a3ae02d759 100644
> --- a/arch/arm/configs/multi_v5_defconfig
> +++ b/arch/arm/configs/multi_v5_defconfig
> @@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
> CONFIG_MTD_NAND_ATMEL=y
> CONFIG_MTD_NAND_ORION=y
> CONFIG_MTD_SPI_NOR=y
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
> +CONFIG_SPI_ASPEED_SMC=y
> CONFIG_MTD_UBI=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_ATMEL_SSC=m
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index fc1b69256b64..33572998dbbe 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
> CONFIG_MTD_NAND_STM32_FMC2=y
> CONFIG_MTD_NAND_PL35X=y
> CONFIG_MTD_SPI_NOR=y
> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
> +CONFIG_SPI_ASPEED_SMC=m
> CONFIG_MTD_UBI=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_RAM=y
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-16 7:21 ` Joel Stanley
-1 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-16 7:21 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Mon, 14 Feb 2022 at 09:42, Cédric Le Goater <clg@kaod.org> wrote:
>
> Hi,
>
> This series adds a new SPI driver using the spi-mem interface for the
> Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> SoCs.
>
> * AST2600 Firmware SPI Memory Controller (FMC)
> * AST2600 SPI Flash Controller (SPI1 and SPI2)
> * AST2500 Firmware SPI Memory Controller (FMC)
> * AST2500 SPI Flash Controller (SPI1 and SPI2)
> * AST2400 New Static Memory Controller (also referred as FMC)
> * AST2400 SPI Flash Controller (SPI)
>
> It is based on the current OpenBMC kernel driver [1], using directly
> the MTD SPI-NOR interface and on a patchset [2] previously proposed
> adding support for the AST2600 only. This driver takes a slightly
> different approach to cover all 6 controllers.
>
> It does not make use of the controller register disabling Address and
> Data byte lanes because is not available on the AST2400 SoC. We could
> introduce a specific handler for new features available on recent SoCs
> if needed. As there is not much difference on performance, the driver
> chooses the common denominator: "User mode" which has been heavily
> tested in [1]. "User mode" is also used as a fall back method when
> flash device mapping window is too small.
>
> Problems to address with spi-mem were the configuration of the mapping
> windows and the calibration of the read timings. The driver handles
> them in the direct mapping handler when some knowledge on the size of
> the flash device is know. It is not perfect but not incorrect either.
> The algorithm is one from [1] because it doesn't require the DMA
> registers which are not available on all controllers.
>
> Direct mapping for writes is not supported (yet). I have seen some
> corruption with writes and I preferred to use the safer and proven
> method of the initial driver [1]. We can improve that later.
>
> The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> didn't have the expected results. Therefore it is not activated yet.
> This needs more tests.
>
> The series does not remove the current Aspeed SMC driver but prepares
> ground for its removal by changing its CONFIG option. This last step
> can be addressed as a followup when the new driver using the spi-mem
> interface has been sufficiently exposed.
>
> Tested on:
>
> * OpenPOWER Palmetto (AST2400)
> * Evaluation board (AST2500)
> * OpenPOWER Witherspoon (AST2500)
> * Evaluation board (AST2600 A0)
> * Rainier board (AST2600)
Looks great! Thanks for doing this work Cédric.
I reviewed all of the patches. The device tree and defconfig ones,
which we will send via my aspeed tree, are good to go.
The others look good too, to the best of my knowledge.
I'll do some more testing of your v2 when you send it out.
Cheers,
Joel
>
> [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
>
> Thanks,
>
> C.
>
> Cédric Le Goater (10):
> mtd: spi-nor: aspeed: Rename Kconfig option
> dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> spi: spi-mem: Add driver for Aspeed SMC controllers
> spi: aspeed: Add support for direct mapping
> spi: aspeed: Adjust direct mapping to device size
> spi: aspeed: Workaround AST2500 limitations
> spi: aspeed: Add support for the AST2400 SPI controller
> spi: aspeed: Calibrate read timings
> ARM: dts: aspeed: Enable Dual SPI RX transfers
> spi: aspeed: Activate new spi-mem driver
>
> drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> 9 files changed, 1369 insertions(+), 3 deletions(-)
> create mode 100644 drivers/spi/spi-aspeed-smc.c
> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-16 7:21 ` Joel Stanley
0 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-16 7:21 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Mon, 14 Feb 2022 at 09:42, Cédric Le Goater <clg@kaod.org> wrote:
>
> Hi,
>
> This series adds a new SPI driver using the spi-mem interface for the
> Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> SoCs.
>
> * AST2600 Firmware SPI Memory Controller (FMC)
> * AST2600 SPI Flash Controller (SPI1 and SPI2)
> * AST2500 Firmware SPI Memory Controller (FMC)
> * AST2500 SPI Flash Controller (SPI1 and SPI2)
> * AST2400 New Static Memory Controller (also referred as FMC)
> * AST2400 SPI Flash Controller (SPI)
>
> It is based on the current OpenBMC kernel driver [1], using directly
> the MTD SPI-NOR interface and on a patchset [2] previously proposed
> adding support for the AST2600 only. This driver takes a slightly
> different approach to cover all 6 controllers.
>
> It does not make use of the controller register disabling Address and
> Data byte lanes because is not available on the AST2400 SoC. We could
> introduce a specific handler for new features available on recent SoCs
> if needed. As there is not much difference on performance, the driver
> chooses the common denominator: "User mode" which has been heavily
> tested in [1]. "User mode" is also used as a fall back method when
> flash device mapping window is too small.
>
> Problems to address with spi-mem were the configuration of the mapping
> windows and the calibration of the read timings. The driver handles
> them in the direct mapping handler when some knowledge on the size of
> the flash device is know. It is not perfect but not incorrect either.
> The algorithm is one from [1] because it doesn't require the DMA
> registers which are not available on all controllers.
>
> Direct mapping for writes is not supported (yet). I have seen some
> corruption with writes and I preferred to use the safer and proven
> method of the initial driver [1]. We can improve that later.
>
> The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> didn't have the expected results. Therefore it is not activated yet.
> This needs more tests.
>
> The series does not remove the current Aspeed SMC driver but prepares
> ground for its removal by changing its CONFIG option. This last step
> can be addressed as a followup when the new driver using the spi-mem
> interface has been sufficiently exposed.
>
> Tested on:
>
> * OpenPOWER Palmetto (AST2400)
> * Evaluation board (AST2500)
> * OpenPOWER Witherspoon (AST2500)
> * Evaluation board (AST2600 A0)
> * Rainier board (AST2600)
Looks great! Thanks for doing this work Cédric.
I reviewed all of the patches. The device tree and defconfig ones,
which we will send via my aspeed tree, are good to go.
The others look good too, to the best of my knowledge.
I'll do some more testing of your v2 when you send it out.
Cheers,
Joel
>
> [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
>
> Thanks,
>
> C.
>
> Cédric Le Goater (10):
> mtd: spi-nor: aspeed: Rename Kconfig option
> dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> spi: spi-mem: Add driver for Aspeed SMC controllers
> spi: aspeed: Add support for direct mapping
> spi: aspeed: Adjust direct mapping to device size
> spi: aspeed: Workaround AST2500 limitations
> spi: aspeed: Add support for the AST2400 SPI controller
> spi: aspeed: Calibrate read timings
> ARM: dts: aspeed: Enable Dual SPI RX transfers
> spi: aspeed: Activate new spi-mem driver
>
> drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> 9 files changed, 1369 insertions(+), 3 deletions(-)
> create mode 100644 drivers/spi/spi-aspeed-smc.c
> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>
> --
> 2.34.1
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-16 7:21 ` Joel Stanley
0 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-16 7:21 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Mon, 14 Feb 2022 at 09:42, Cédric Le Goater <clg@kaod.org> wrote:
>
> Hi,
>
> This series adds a new SPI driver using the spi-mem interface for the
> Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> SoCs.
>
> * AST2600 Firmware SPI Memory Controller (FMC)
> * AST2600 SPI Flash Controller (SPI1 and SPI2)
> * AST2500 Firmware SPI Memory Controller (FMC)
> * AST2500 SPI Flash Controller (SPI1 and SPI2)
> * AST2400 New Static Memory Controller (also referred as FMC)
> * AST2400 SPI Flash Controller (SPI)
>
> It is based on the current OpenBMC kernel driver [1], using directly
> the MTD SPI-NOR interface and on a patchset [2] previously proposed
> adding support for the AST2600 only. This driver takes a slightly
> different approach to cover all 6 controllers.
>
> It does not make use of the controller register disabling Address and
> Data byte lanes because is not available on the AST2400 SoC. We could
> introduce a specific handler for new features available on recent SoCs
> if needed. As there is not much difference on performance, the driver
> chooses the common denominator: "User mode" which has been heavily
> tested in [1]. "User mode" is also used as a fall back method when
> flash device mapping window is too small.
>
> Problems to address with spi-mem were the configuration of the mapping
> windows and the calibration of the read timings. The driver handles
> them in the direct mapping handler when some knowledge on the size of
> the flash device is know. It is not perfect but not incorrect either.
> The algorithm is one from [1] because it doesn't require the DMA
> registers which are not available on all controllers.
>
> Direct mapping for writes is not supported (yet). I have seen some
> corruption with writes and I preferred to use the safer and proven
> method of the initial driver [1]. We can improve that later.
>
> The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> didn't have the expected results. Therefore it is not activated yet.
> This needs more tests.
>
> The series does not remove the current Aspeed SMC driver but prepares
> ground for its removal by changing its CONFIG option. This last step
> can be addressed as a followup when the new driver using the spi-mem
> interface has been sufficiently exposed.
>
> Tested on:
>
> * OpenPOWER Palmetto (AST2400)
> * Evaluation board (AST2500)
> * OpenPOWER Witherspoon (AST2500)
> * Evaluation board (AST2600 A0)
> * Rainier board (AST2600)
Looks great! Thanks for doing this work Cédric.
I reviewed all of the patches. The device tree and defconfig ones,
which we will send via my aspeed tree, are good to go.
The others look good too, to the best of my knowledge.
I'll do some more testing of your v2 when you send it out.
Cheers,
Joel
>
> [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
>
> Thanks,
>
> C.
>
> Cédric Le Goater (10):
> mtd: spi-nor: aspeed: Rename Kconfig option
> dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> spi: spi-mem: Add driver for Aspeed SMC controllers
> spi: aspeed: Add support for direct mapping
> spi: aspeed: Adjust direct mapping to device size
> spi: aspeed: Workaround AST2500 limitations
> spi: aspeed: Add support for the AST2400 SPI controller
> spi: aspeed: Calibrate read timings
> ARM: dts: aspeed: Enable Dual SPI RX transfers
> spi: aspeed: Activate new spi-mem driver
>
> drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> 9 files changed, 1369 insertions(+), 3 deletions(-)
> create mode 100644 drivers/spi/spi-aspeed-smc.c
> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>
> --
> 2.34.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] 115+ messages in thread
* Re: [PATCH 09/10] ARM: dts: aspeed: Enable Dual SPI RX transfers
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-16 7:21 ` Joel Stanley
-1 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-16 7:21 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Mon, 14 Feb 2022 at 09:43, Cédric Le Goater <clg@kaod.org> wrote:
>
> All these controllers support at least Dual SPI. Update the DTs.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 ++++++
> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +++++++
> arch/arm/boot/dts/aspeed-g6.dtsi | 8 ++++++++
> 3 files changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index f14dace34c5a..da211fbd8658 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -65,27 +65,32 @@ fmc: spi@1e620000 {
> flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> spi-max-frequency = <50000000>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@3 {
> reg = < 3 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@4 {
> reg = < 4 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -102,6 +107,7 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 7495f93c5069..804b66d32127 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -67,18 +67,21 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -95,12 +98,14 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -117,12 +122,14 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
> index c32e87fad4dc..542714c61a85 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -107,18 +107,21 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -135,12 +138,14 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -157,18 +162,21 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 09/10] ARM: dts: aspeed: Enable Dual SPI RX transfers
@ 2022-02-16 7:21 ` Joel Stanley
0 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-16 7:21 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Mon, 14 Feb 2022 at 09:43, Cédric Le Goater <clg@kaod.org> wrote:
>
> All these controllers support at least Dual SPI. Update the DTs.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 ++++++
> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +++++++
> arch/arm/boot/dts/aspeed-g6.dtsi | 8 ++++++++
> 3 files changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index f14dace34c5a..da211fbd8658 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -65,27 +65,32 @@ fmc: spi@1e620000 {
> flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> spi-max-frequency = <50000000>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@3 {
> reg = < 3 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@4 {
> reg = < 4 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -102,6 +107,7 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 7495f93c5069..804b66d32127 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -67,18 +67,21 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -95,12 +98,14 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -117,12 +122,14 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
> index c32e87fad4dc..542714c61a85 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -107,18 +107,21 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -135,12 +138,14 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -157,18 +162,21 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> --
> 2.34.1
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 09/10] ARM: dts: aspeed: Enable Dual SPI RX transfers
@ 2022-02-16 7:21 ` Joel Stanley
0 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-16 7:21 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Mon, 14 Feb 2022 at 09:43, Cédric Le Goater <clg@kaod.org> wrote:
>
> All these controllers support at least Dual SPI. Update the DTs.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 ++++++
> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +++++++
> arch/arm/boot/dts/aspeed-g6.dtsi | 8 ++++++++
> 3 files changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index f14dace34c5a..da211fbd8658 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -65,27 +65,32 @@ fmc: spi@1e620000 {
> flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> spi-max-frequency = <50000000>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@3 {
> reg = < 3 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@4 {
> reg = < 4 >;
> compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -102,6 +107,7 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 7495f93c5069..804b66d32127 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -67,18 +67,21 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -95,12 +98,14 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -117,12 +122,14 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
> index c32e87fad4dc..542714c61a85 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -107,18 +107,21 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -135,12 +138,14 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> @@ -157,18 +162,21 @@ flash@0 {
> reg = < 0 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@1 {
> reg = < 1 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> flash@2 {
> reg = < 2 >;
> compatible = "jedec,spi-nor";
> spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <2>;
> status = "disabled";
> };
> };
> --
> 2.34.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] 115+ messages in thread
* Re: [PATCH 10/10] spi: aspeed: Activate new spi-mem driver
2022-02-16 7:02 ` Joel Stanley
(?)
@ 2022-02-16 8:12 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-16 8:12 UTC (permalink / raw)
To: Joel Stanley
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On 2/16/22 08:02, Joel Stanley wrote:
> On Mon, 14 Feb 2022 at 09:43, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> The previous driver using the MTD SPI NOR interface is kept in case we
>> find some issues but we should remove it quickly once the new driver
>> using the spi-mem interface has been sufficiently exposed.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>
> I suggest we drop the defconfig changes from both this patch and the
> first. This way we'll always have the new driver being built, with
> less churn.
>
> If you strongly prefer the way you've done it then that's fine too.
I am fine with that, but, with only patch 1, the defconfig files would
be referencing an non-existing CONFIG. Is that ok ?
Thanks,
C.
>
>> ---
>> arch/arm/configs/aspeed_g4_defconfig | 2 +-
>> arch/arm/configs/aspeed_g5_defconfig | 2 +-
>> arch/arm/configs/multi_v5_defconfig | 2 +-
>> arch/arm/configs/multi_v7_defconfig | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
>> index 964536444cd7..b4a1b2ed1a17 100644
>> --- a/arch/arm/configs/aspeed_g4_defconfig
>> +++ b/arch/arm/configs/aspeed_g4_defconfig
>> @@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
>> CONFIG_MTD_PARTITIONED_MASTER=y
>> CONFIG_MTD_SPI_NOR=y
>> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
>> +CONFIG_SPI_ASPEED_SMC=y
>> CONFIG_MTD_UBI=y
>> CONFIG_MTD_UBI_FASTMAP=y
>> CONFIG_MTD_UBI_BLOCK=y
>> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
>> index e809236ca88b..ccc4240ee4b5 100644
>> --- a/arch/arm/configs/aspeed_g5_defconfig
>> +++ b/arch/arm/configs/aspeed_g5_defconfig
>> @@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
>> CONFIG_MTD_PARTITIONED_MASTER=y
>> CONFIG_MTD_SPI_NOR=y
>> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
>> +CONFIG_SPI_ASPEED_SMC=y
>> CONFIG_MTD_UBI=y
>> CONFIG_MTD_UBI_FASTMAP=y
>> CONFIG_MTD_UBI_BLOCK=y
>> diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
>> index 49083ef05fb0..80a3ae02d759 100644
>> --- a/arch/arm/configs/multi_v5_defconfig
>> +++ b/arch/arm/configs/multi_v5_defconfig
>> @@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
>> CONFIG_MTD_NAND_ATMEL=y
>> CONFIG_MTD_NAND_ORION=y
>> CONFIG_MTD_SPI_NOR=y
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
>> +CONFIG_SPI_ASPEED_SMC=y
>> CONFIG_MTD_UBI=y
>> CONFIG_BLK_DEV_LOOP=y
>> CONFIG_ATMEL_SSC=m
>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> index fc1b69256b64..33572998dbbe 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
>> CONFIG_MTD_NAND_STM32_FMC2=y
>> CONFIG_MTD_NAND_PL35X=y
>> CONFIG_MTD_SPI_NOR=y
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
>> +CONFIG_SPI_ASPEED_SMC=m
>> CONFIG_MTD_UBI=y
>> CONFIG_BLK_DEV_LOOP=y
>> CONFIG_BLK_DEV_RAM=y
>> --
>> 2.34.1
>>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 10/10] spi: aspeed: Activate new spi-mem driver
@ 2022-02-16 8:12 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-16 8:12 UTC (permalink / raw)
To: Joel Stanley
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On 2/16/22 08:02, Joel Stanley wrote:
> On Mon, 14 Feb 2022 at 09:43, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> The previous driver using the MTD SPI NOR interface is kept in case we
>> find some issues but we should remove it quickly once the new driver
>> using the spi-mem interface has been sufficiently exposed.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>
> I suggest we drop the defconfig changes from both this patch and the
> first. This way we'll always have the new driver being built, with
> less churn.
>
> If you strongly prefer the way you've done it then that's fine too.
I am fine with that, but, with only patch 1, the defconfig files would
be referencing an non-existing CONFIG. Is that ok ?
Thanks,
C.
>
>> ---
>> arch/arm/configs/aspeed_g4_defconfig | 2 +-
>> arch/arm/configs/aspeed_g5_defconfig | 2 +-
>> arch/arm/configs/multi_v5_defconfig | 2 +-
>> arch/arm/configs/multi_v7_defconfig | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
>> index 964536444cd7..b4a1b2ed1a17 100644
>> --- a/arch/arm/configs/aspeed_g4_defconfig
>> +++ b/arch/arm/configs/aspeed_g4_defconfig
>> @@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
>> CONFIG_MTD_PARTITIONED_MASTER=y
>> CONFIG_MTD_SPI_NOR=y
>> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
>> +CONFIG_SPI_ASPEED_SMC=y
>> CONFIG_MTD_UBI=y
>> CONFIG_MTD_UBI_FASTMAP=y
>> CONFIG_MTD_UBI_BLOCK=y
>> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
>> index e809236ca88b..ccc4240ee4b5 100644
>> --- a/arch/arm/configs/aspeed_g5_defconfig
>> +++ b/arch/arm/configs/aspeed_g5_defconfig
>> @@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
>> CONFIG_MTD_PARTITIONED_MASTER=y
>> CONFIG_MTD_SPI_NOR=y
>> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
>> +CONFIG_SPI_ASPEED_SMC=y
>> CONFIG_MTD_UBI=y
>> CONFIG_MTD_UBI_FASTMAP=y
>> CONFIG_MTD_UBI_BLOCK=y
>> diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
>> index 49083ef05fb0..80a3ae02d759 100644
>> --- a/arch/arm/configs/multi_v5_defconfig
>> +++ b/arch/arm/configs/multi_v5_defconfig
>> @@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
>> CONFIG_MTD_NAND_ATMEL=y
>> CONFIG_MTD_NAND_ORION=y
>> CONFIG_MTD_SPI_NOR=y
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
>> +CONFIG_SPI_ASPEED_SMC=y
>> CONFIG_MTD_UBI=y
>> CONFIG_BLK_DEV_LOOP=y
>> CONFIG_ATMEL_SSC=m
>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> index fc1b69256b64..33572998dbbe 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
>> CONFIG_MTD_NAND_STM32_FMC2=y
>> CONFIG_MTD_NAND_PL35X=y
>> CONFIG_MTD_SPI_NOR=y
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
>> +CONFIG_SPI_ASPEED_SMC=m
>> CONFIG_MTD_UBI=y
>> CONFIG_BLK_DEV_LOOP=y
>> CONFIG_BLK_DEV_RAM=y
>> --
>> 2.34.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] 115+ messages in thread
* Re: [PATCH 10/10] spi: aspeed: Activate new spi-mem driver
@ 2022-02-16 8:12 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-16 8:12 UTC (permalink / raw)
To: Joel Stanley
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On 2/16/22 08:02, Joel Stanley wrote:
> On Mon, 14 Feb 2022 at 09:43, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> The previous driver using the MTD SPI NOR interface is kept in case we
>> find some issues but we should remove it quickly once the new driver
>> using the spi-mem interface has been sufficiently exposed.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>
> I suggest we drop the defconfig changes from both this patch and the
> first. This way we'll always have the new driver being built, with
> less churn.
>
> If you strongly prefer the way you've done it then that's fine too.
I am fine with that, but, with only patch 1, the defconfig files would
be referencing an non-existing CONFIG. Is that ok ?
Thanks,
C.
>
>> ---
>> arch/arm/configs/aspeed_g4_defconfig | 2 +-
>> arch/arm/configs/aspeed_g5_defconfig | 2 +-
>> arch/arm/configs/multi_v5_defconfig | 2 +-
>> arch/arm/configs/multi_v7_defconfig | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
>> index 964536444cd7..b4a1b2ed1a17 100644
>> --- a/arch/arm/configs/aspeed_g4_defconfig
>> +++ b/arch/arm/configs/aspeed_g4_defconfig
>> @@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y
>> CONFIG_MTD_PARTITIONED_MASTER=y
>> CONFIG_MTD_SPI_NOR=y
>> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
>> +CONFIG_SPI_ASPEED_SMC=y
>> CONFIG_MTD_UBI=y
>> CONFIG_MTD_UBI_FASTMAP=y
>> CONFIG_MTD_UBI_BLOCK=y
>> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
>> index e809236ca88b..ccc4240ee4b5 100644
>> --- a/arch/arm/configs/aspeed_g5_defconfig
>> +++ b/arch/arm/configs/aspeed_g5_defconfig
>> @@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y
>> CONFIG_MTD_PARTITIONED_MASTER=y
>> CONFIG_MTD_SPI_NOR=y
>> # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
>> +CONFIG_SPI_ASPEED_SMC=y
>> CONFIG_MTD_UBI=y
>> CONFIG_MTD_UBI_FASTMAP=y
>> CONFIG_MTD_UBI_BLOCK=y
>> diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
>> index 49083ef05fb0..80a3ae02d759 100644
>> --- a/arch/arm/configs/multi_v5_defconfig
>> +++ b/arch/arm/configs/multi_v5_defconfig
>> @@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y
>> CONFIG_MTD_NAND_ATMEL=y
>> CONFIG_MTD_NAND_ORION=y
>> CONFIG_MTD_SPI_NOR=y
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y
>> +CONFIG_SPI_ASPEED_SMC=y
>> CONFIG_MTD_UBI=y
>> CONFIG_BLK_DEV_LOOP=y
>> CONFIG_ATMEL_SSC=m
>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> index fc1b69256b64..33572998dbbe 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y
>> CONFIG_MTD_NAND_STM32_FMC2=y
>> CONFIG_MTD_NAND_PL35X=y
>> CONFIG_MTD_SPI_NOR=y
>> -CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m
>> +CONFIG_SPI_ASPEED_SMC=m
>> CONFIG_MTD_UBI=y
>> CONFIG_BLK_DEV_LOOP=y
>> CONFIG_BLK_DEV_RAM=y
>> --
>> 2.34.1
>>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
2022-02-15 21:06 ` Rob Herring
(?)
@ 2022-02-17 8:37 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-17 8:37 UTC (permalink / raw)
To: Rob Herring
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, linux-arm-kernel, linux-kernel
On 2/15/22 22:06, Rob Herring wrote:
> On Mon, Feb 14, 2022 at 10:42:23AM +0100, Cédric Le Goater wrote:
>> The "interrupt" property is optional because it is only necessary for
>> controllers supporting DMAs (Not implemented yet in the new driver).
>>
>> Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
>> 1 file changed, 92 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>> new file mode 100644
>> index 000000000000..ed71c4d86930
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>> @@ -0,0 +1,92 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Aspeed SMC controllers bindings
>> +
>> +maintainers:
>> + - Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>> + - Cédric Le Goater <clg@kaod.org>
>> +
>> +description: |
>> + This binding describes the Aspeed Static Memory Controllers (FMC and
>> + SPI) of the AST2400, AST2500 and AST2600 SOCs.
>> +
>> +allOf:
>> + - $ref: "spi-controller.yaml#"
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - aspeed,ast2600-fmc
>> + - aspeed,ast2600-spi
>> + - aspeed,ast2500-fmc
>> + - aspeed,ast2500-spi
>> + - aspeed,ast2400-fmc
>> + - aspeed,ast2400-spi
>> +
>> + reg:
>> + items:
>> + - description: registers
>> + - description: memory mapping
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> +patternProperties:
>> + "@[0-9a-f]+":
>> + type: object
>> +
>> + properties:
>> + spi-rx-bus-width:
>> + enum: [1, 2, 4]
>> +
>> + required:
>> + - reg
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
>> + #include <dt-bindings/clock/ast2600-clock.h>
>> +
>> + spi@1e620000 {
>> + reg = < 0x1e620000 0xc4
>> + 0x20000000 0x10000000 >;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "aspeed,ast2600-fmc";
>> + clocks = <&syscon ASPEED_CLK_AHB>;
>> + status = "disabled";
>
> Why is your example disabled? Drop 'status'.
my bad. I took the basic definition of the SoC and the devices
are activated in the boards. I will fix in v2.
Thanks,
C.
>
>> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>> + flash@0 {
>> + reg = < 0 >;
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <50000000>;
>> + status = "disabled";
>
> Ditto.
>
>> + };
>> + flash@1 {
>> + reg = < 1 >;
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <50000000>;
>> + status = "disabled";
>> + };
>> + flash@2 {
>> + reg = < 2 >;
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <50000000>;
>> + status = "disabled";
>> + };
>> + };
>> --
>> 2.34.1
>>
>>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
@ 2022-02-17 8:37 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-17 8:37 UTC (permalink / raw)
To: Rob Herring
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, linux-arm-kernel, linux-kernel
On 2/15/22 22:06, Rob Herring wrote:
> On Mon, Feb 14, 2022 at 10:42:23AM +0100, Cédric Le Goater wrote:
>> The "interrupt" property is optional because it is only necessary for
>> controllers supporting DMAs (Not implemented yet in the new driver).
>>
>> Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
>> 1 file changed, 92 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>> new file mode 100644
>> index 000000000000..ed71c4d86930
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>> @@ -0,0 +1,92 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Aspeed SMC controllers bindings
>> +
>> +maintainers:
>> + - Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>> + - Cédric Le Goater <clg@kaod.org>
>> +
>> +description: |
>> + This binding describes the Aspeed Static Memory Controllers (FMC and
>> + SPI) of the AST2400, AST2500 and AST2600 SOCs.
>> +
>> +allOf:
>> + - $ref: "spi-controller.yaml#"
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - aspeed,ast2600-fmc
>> + - aspeed,ast2600-spi
>> + - aspeed,ast2500-fmc
>> + - aspeed,ast2500-spi
>> + - aspeed,ast2400-fmc
>> + - aspeed,ast2400-spi
>> +
>> + reg:
>> + items:
>> + - description: registers
>> + - description: memory mapping
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> +patternProperties:
>> + "@[0-9a-f]+":
>> + type: object
>> +
>> + properties:
>> + spi-rx-bus-width:
>> + enum: [1, 2, 4]
>> +
>> + required:
>> + - reg
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
>> + #include <dt-bindings/clock/ast2600-clock.h>
>> +
>> + spi@1e620000 {
>> + reg = < 0x1e620000 0xc4
>> + 0x20000000 0x10000000 >;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "aspeed,ast2600-fmc";
>> + clocks = <&syscon ASPEED_CLK_AHB>;
>> + status = "disabled";
>
> Why is your example disabled? Drop 'status'.
my bad. I took the basic definition of the SoC and the devices
are activated in the boards. I will fix in v2.
Thanks,
C.
>
>> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>> + flash@0 {
>> + reg = < 0 >;
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <50000000>;
>> + status = "disabled";
>
> Ditto.
>
>> + };
>> + flash@1 {
>> + reg = < 1 >;
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <50000000>;
>> + status = "disabled";
>> + };
>> + flash@2 {
>> + reg = < 2 >;
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <50000000>;
>> + status = "disabled";
>> + };
>> + };
>> --
>> 2.34.1
>>
>>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding
@ 2022-02-17 8:37 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-17 8:37 UTC (permalink / raw)
To: Rob Herring
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Pratyush Yadav,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Joel Stanley, Andrew Jeffery, Chin-Ting Kuo,
devicetree, linux-arm-kernel, linux-kernel
On 2/15/22 22:06, Rob Herring wrote:
> On Mon, Feb 14, 2022 at 10:42:23AM +0100, Cédric Le Goater wrote:
>> The "interrupt" property is optional because it is only necessary for
>> controllers supporting DMAs (Not implemented yet in the new driver).
>>
>> Cc: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 +++++++++++++++++++
>> 1 file changed, 92 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>> new file mode 100644
>> index 000000000000..ed71c4d86930
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>> @@ -0,0 +1,92 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Aspeed SMC controllers bindings
>> +
>> +maintainers:
>> + - Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>> + - Cédric Le Goater <clg@kaod.org>
>> +
>> +description: |
>> + This binding describes the Aspeed Static Memory Controllers (FMC and
>> + SPI) of the AST2400, AST2500 and AST2600 SOCs.
>> +
>> +allOf:
>> + - $ref: "spi-controller.yaml#"
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - aspeed,ast2600-fmc
>> + - aspeed,ast2600-spi
>> + - aspeed,ast2500-fmc
>> + - aspeed,ast2500-spi
>> + - aspeed,ast2400-fmc
>> + - aspeed,ast2400-spi
>> +
>> + reg:
>> + items:
>> + - description: registers
>> + - description: memory mapping
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> +patternProperties:
>> + "@[0-9a-f]+":
>> + type: object
>> +
>> + properties:
>> + spi-rx-bus-width:
>> + enum: [1, 2, 4]
>> +
>> + required:
>> + - reg
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/interrupt-controller/aspeed-scu-ic.h>
>> + #include <dt-bindings/clock/ast2600-clock.h>
>> +
>> + spi@1e620000 {
>> + reg = < 0x1e620000 0xc4
>> + 0x20000000 0x10000000 >;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "aspeed,ast2600-fmc";
>> + clocks = <&syscon ASPEED_CLK_AHB>;
>> + status = "disabled";
>
> Why is your example disabled? Drop 'status'.
my bad. I took the basic definition of the SoC and the devices
are activated in the boards. I will fix in v2.
Thanks,
C.
>
>> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>> + flash@0 {
>> + reg = < 0 >;
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <50000000>;
>> + status = "disabled";
>
> Ditto.
>
>> + };
>> + flash@1 {
>> + reg = < 1 >;
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <50000000>;
>> + status = "disabled";
>> + };
>> + flash@2 {
>> + reg = < 2 >;
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <50000000>;
>> + status = "disabled";
>> + };
>> + };
>> --
>> 2.34.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] 115+ messages in thread
* Call for testing: spi-mem driver for Aspeed SMC controllers
2022-02-14 9:42 ` Cédric Le Goater
` (12 preceding siblings ...)
(?)
@ 2022-02-25 5:29 ` Joel Stanley
2022-02-27 18:53 ` Cédric Le Goater
2022-03-01 9:57 ` John Wang
-1 siblings, 2 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-25 5:29 UTC (permalink / raw)
To: OpenBMC Maillist; +Cc: Lei Yu, Ryan Chen, Cédric Le Goater
Cedric has authored a new drive for the SPI NOR devices on the ASPEED
SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
subsystem, which should mean it can go upstream.
This is great news, as our current driver is half upstream, half in
the openbmc tree, due to some issues getting it merged as part of the
spi-nor subsystem.
It would be great to have testing. I've created a commit that patches
in support to whatever kernel tree you're using. Hopefully this makes
it easier to test atop your internal branches:
https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
Cherry pick this commit into your tree, and see how it goes, and report back.
I plan to switch the openbmc tree to this driver when we next rebase
the kernel. We could also backport it to dev-5.15 as an option.
You can direct testing results to this thread, or reply directly to
the upstream thread:
https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
Cheers,
Joel
---------- Forwarded message ---------
From: Cédric Le Goater <clg@kaod.org>
Date: Mon, 14 Feb 2022 at 09:42
Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
<tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
<richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
<linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
<chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
Hi,
This series adds a new SPI driver using the spi-mem interface for the
Aspeed static memory controllers of the AST2600, AST2500 and AST2400
SoCs.
* AST2600 Firmware SPI Memory Controller (FMC)
* AST2600 SPI Flash Controller (SPI1 and SPI2)
* AST2500 Firmware SPI Memory Controller (FMC)
* AST2500 SPI Flash Controller (SPI1 and SPI2)
* AST2400 New Static Memory Controller (also referred as FMC)
* AST2400 SPI Flash Controller (SPI)
It is based on the current OpenBMC kernel driver [1], using directly
the MTD SPI-NOR interface and on a patchset [2] previously proposed
adding support for the AST2600 only. This driver takes a slightly
different approach to cover all 6 controllers.
It does not make use of the controller register disabling Address and
Data byte lanes because is not available on the AST2400 SoC. We could
introduce a specific handler for new features available on recent SoCs
if needed. As there is not much difference on performance, the driver
chooses the common denominator: "User mode" which has been heavily
tested in [1]. "User mode" is also used as a fall back method when
flash device mapping window is too small.
Problems to address with spi-mem were the configuration of the mapping
windows and the calibration of the read timings. The driver handles
them in the direct mapping handler when some knowledge on the size of
the flash device is know. It is not perfect but not incorrect either.
The algorithm is one from [1] because it doesn't require the DMA
registers which are not available on all controllers.
Direct mapping for writes is not supported (yet). I have seen some
corruption with writes and I preferred to use the safer and proven
method of the initial driver [1]. We can improve that later.
The driver supports Quad SPI RX transfers on the AST2600 SoC but it
didn't have the expected results. Therefore it is not activated yet.
This needs more tests.
The series does not remove the current Aspeed SMC driver but prepares
ground for its removal by changing its CONFIG option. This last step
can be addressed as a followup when the new driver using the spi-mem
interface has been sufficiently exposed.
Tested on:
* OpenPOWER Palmetto (AST2400)
* Evaluation board (AST2500)
* OpenPOWER Witherspoon (AST2500)
* Evaluation board (AST2600 A0)
* Rainier board (AST2600)
[1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
[2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
Thanks,
C.
Cédric Le Goater (10):
mtd: spi-nor: aspeed: Rename Kconfig option
dt-bindings: spi: Add Aspeed SMC controllers device tree binding
spi: spi-mem: Add driver for Aspeed SMC controllers
spi: aspeed: Add support for direct mapping
spi: aspeed: Adjust direct mapping to device size
spi: aspeed: Workaround AST2500 limitations
spi: aspeed: Add support for the AST2400 SPI controller
spi: aspeed: Calibrate read timings
ARM: dts: aspeed: Enable Dual SPI RX transfers
spi: aspeed: Activate new spi-mem driver
drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
.../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
drivers/mtd/spi-nor/controllers/Makefile | 2 +-
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
9 files changed, 1369 insertions(+), 3 deletions(-)
create mode 100644 drivers/spi/spi-aspeed-smc.c
create mode 100644
Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
--
2.34.1
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-25 7:31 ` Pratyush Yadav
-1 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 7:31 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> To prepare transition to the new Aspeed SMC SPI controller driver using
> the spi-mem interface, change the kernel CONFIG option of the current
> driver to reflect that the implementation uses the MTD SPI-NOR interface.
> Once the new driver is sufficiently exposed, we should remove the old one.
I don't quite understand the reasoning behind this. Why keep the old
driver around? Why not directly replace it with the new one? Does the
new one have any limitations that this one doesn't?
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-25 7:31 ` Pratyush Yadav
0 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 7:31 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> To prepare transition to the new Aspeed SMC SPI controller driver using
> the spi-mem interface, change the kernel CONFIG option of the current
> driver to reflect that the implementation uses the MTD SPI-NOR interface.
> Once the new driver is sufficiently exposed, we should remove the old one.
I don't quite understand the reasoning behind this. Why keep the old
driver around? Why not directly replace it with the new one? Does the
new one have any limitations that this one doesn't?
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-25 7:31 ` Pratyush Yadav
0 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 7:31 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> To prepare transition to the new Aspeed SMC SPI controller driver using
> the spi-mem interface, change the kernel CONFIG option of the current
> driver to reflect that the implementation uses the MTD SPI-NOR interface.
> Once the new driver is sufficiently exposed, we should remove the old one.
I don't quite understand the reasoning behind this. Why keep the old
driver around? Why not directly replace it with the new one? Does the
new one have any limitations that this one doesn't?
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
_______________________________________________
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] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-25 7:50 ` Pratyush Yadav
-1 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 7:50 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> This SPI driver adds support for the Aspeed static memory controllers
> of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
>
> * AST2600 Firmware SPI Memory Controller (FMC)
> . BMC firmware
> . 3 chip select pins (CE0 ~ CE2)
> . Only supports SPI type flash memory
> . different segment register interface
> . single, dual and quad mode.
>
> * AST2600 SPI Flash Controller (SPI1 and SPI2)
> . host firmware
> . 2 chip select pins (CE0 ~ CE1)
> . different segment register interface
> . single, dual and quad mode.
>
> * AST2500 Firmware SPI Memory Controller (FMC)
> . BMC firmware
> . 3 chip select pins (CE0 ~ CE2)
> . supports SPI type flash memory (CE0-CE1)
> . CE2 can be of NOR type flash but this is not supported by the driver
> . single, dual mode.
>
> * AST2500 SPI Flash Controller (SPI1 and SPI2)
> . host firmware
> . 2 chip select pins (CE0 ~ CE1)
> . single, dual mode.
>
> * AST2400 New Static Memory Controller (also referred as FMC)
> . BMC firmware
> . New register set
> . 5 chip select pins (CE0 ∼ CE4)
> . supports NOR flash, NAND flash and SPI flash memory.
> . single, dual and quad mode.
>
> Each controller has a memory range on which flash devices contents are
> mapped. Each device is assigned a window that can be changed at bootime
> with the Segment Address Registers.
>
> Each SPI flash device can then be accessed in two modes: Command and
> User. When in User mode, SPI transfers are initiated with accesses to
> the memory segment of a device. When in Command mode, memory
> operations on the memory segment of a device generate SPI commands
> automatically using a Control Register for the settings.
>
> This initial patch adds support for User mode. Command mode needs a little
> more work to check that the memory window on the AHB bus fits the device
> size. It will come later when support for direct mapping is added.
>
> Single and dual mode RX transfers are supported. Other types than SPI
> are not supported.
>
> Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> drivers/spi/spi-aspeed-smc.c | 766 ++++++++++++++++++++++++
> drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> 4 files changed, 779 insertions(+), 1 deletion(-)
> create mode 100644 drivers/spi/spi-aspeed-smc.c
>
[...]
> +
> +/* support for 1-1-1, 1-1-2 or 1-1-4 */
> +static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
> +{
> + if (op->cmd.buswidth > 1)
> + return false;
> +
> + if (op->addr.nbytes != 0) {
> + if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
> + return false;
> + }
> +
> + if (op->dummy.nbytes != 0) {
> + if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
> + return false;
> + }
> +
> + if (op->data.nbytes != 0 && op->data.buswidth > 4)
> + return false;
> +
> + if (!spi_mem_default_supports_op(mem, op))
> + return false;
> +
> + return true;
Nitpick: You can just do return spi_mem_default_supports_op(mem, op);
> +}
> +
[...]
> +
> +static int aspeed_spi_init_devices(struct platform_device *pdev, struct aspeed_spi *aspi)
> +{
> + struct device_node *np;
> + unsigned int cs;
> + int ret;
> +
> + for_each_available_child_of_node(aspi->dev->of_node, np) {
> + struct aspeed_spi_chip *chip;
> +
> + if (!of_device_is_compatible(np, "jedec,spi-nor"))
> + continue;
> +
> + ret = of_property_read_u32(np, "reg", &cs);
> + if (ret) {
> + dev_err(aspi->dev, "Couldn't not read chip select.\n");
> + of_node_put(np);
> + return ret;
> + }
> +
> + if (cs > aspi->data->max_cs) {
> + dev_err(aspi->dev, "Chip select %d out of range.\n", cs);
> + of_node_put(np);
> + return -ERANGE;
> + }
> +
> + chip = &aspi->chips[cs];
> + chip->aspi = aspi;
> + chip->cs = cs;
> +
> + ret = aspeed_spi_chip_init(chip);
> + if (ret) {
> + of_node_put(np);
> + return ret;
> + }
> +
> + if (of_property_read_u32(np, "spi-max-frequency", &chip->clk_freq))
> + chip->clk_freq = ASPEED_SPI_DEFAULT_FREQ;
> +
> + aspi->num_cs++;
> + }
SPI MEM already gives you all this information. Get it from there, don't
parse it yourself.
You can get Chip Select via spi_mem->spi->chip_select.
You can get clock frequency via spi_mem->spi->max_speed_hz.
With these comments fixed,
Acked-by: Pratyush Yadav <p.yadav@ti.com>
> +
> + return 0;
> +}
> +
[...]
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-25 7:50 ` Pratyush Yadav
0 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 7:50 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> This SPI driver adds support for the Aspeed static memory controllers
> of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
>
> * AST2600 Firmware SPI Memory Controller (FMC)
> . BMC firmware
> . 3 chip select pins (CE0 ~ CE2)
> . Only supports SPI type flash memory
> . different segment register interface
> . single, dual and quad mode.
>
> * AST2600 SPI Flash Controller (SPI1 and SPI2)
> . host firmware
> . 2 chip select pins (CE0 ~ CE1)
> . different segment register interface
> . single, dual and quad mode.
>
> * AST2500 Firmware SPI Memory Controller (FMC)
> . BMC firmware
> . 3 chip select pins (CE0 ~ CE2)
> . supports SPI type flash memory (CE0-CE1)
> . CE2 can be of NOR type flash but this is not supported by the driver
> . single, dual mode.
>
> * AST2500 SPI Flash Controller (SPI1 and SPI2)
> . host firmware
> . 2 chip select pins (CE0 ~ CE1)
> . single, dual mode.
>
> * AST2400 New Static Memory Controller (also referred as FMC)
> . BMC firmware
> . New register set
> . 5 chip select pins (CE0 ∼ CE4)
> . supports NOR flash, NAND flash and SPI flash memory.
> . single, dual and quad mode.
>
> Each controller has a memory range on which flash devices contents are
> mapped. Each device is assigned a window that can be changed at bootime
> with the Segment Address Registers.
>
> Each SPI flash device can then be accessed in two modes: Command and
> User. When in User mode, SPI transfers are initiated with accesses to
> the memory segment of a device. When in Command mode, memory
> operations on the memory segment of a device generate SPI commands
> automatically using a Control Register for the settings.
>
> This initial patch adds support for User mode. Command mode needs a little
> more work to check that the memory window on the AHB bus fits the device
> size. It will come later when support for direct mapping is added.
>
> Single and dual mode RX transfers are supported. Other types than SPI
> are not supported.
>
> Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> drivers/spi/spi-aspeed-smc.c | 766 ++++++++++++++++++++++++
> drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> 4 files changed, 779 insertions(+), 1 deletion(-)
> create mode 100644 drivers/spi/spi-aspeed-smc.c
>
[...]
> +
> +/* support for 1-1-1, 1-1-2 or 1-1-4 */
> +static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
> +{
> + if (op->cmd.buswidth > 1)
> + return false;
> +
> + if (op->addr.nbytes != 0) {
> + if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
> + return false;
> + }
> +
> + if (op->dummy.nbytes != 0) {
> + if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
> + return false;
> + }
> +
> + if (op->data.nbytes != 0 && op->data.buswidth > 4)
> + return false;
> +
> + if (!spi_mem_default_supports_op(mem, op))
> + return false;
> +
> + return true;
Nitpick: You can just do return spi_mem_default_supports_op(mem, op);
> +}
> +
[...]
> +
> +static int aspeed_spi_init_devices(struct platform_device *pdev, struct aspeed_spi *aspi)
> +{
> + struct device_node *np;
> + unsigned int cs;
> + int ret;
> +
> + for_each_available_child_of_node(aspi->dev->of_node, np) {
> + struct aspeed_spi_chip *chip;
> +
> + if (!of_device_is_compatible(np, "jedec,spi-nor"))
> + continue;
> +
> + ret = of_property_read_u32(np, "reg", &cs);
> + if (ret) {
> + dev_err(aspi->dev, "Couldn't not read chip select.\n");
> + of_node_put(np);
> + return ret;
> + }
> +
> + if (cs > aspi->data->max_cs) {
> + dev_err(aspi->dev, "Chip select %d out of range.\n", cs);
> + of_node_put(np);
> + return -ERANGE;
> + }
> +
> + chip = &aspi->chips[cs];
> + chip->aspi = aspi;
> + chip->cs = cs;
> +
> + ret = aspeed_spi_chip_init(chip);
> + if (ret) {
> + of_node_put(np);
> + return ret;
> + }
> +
> + if (of_property_read_u32(np, "spi-max-frequency", &chip->clk_freq))
> + chip->clk_freq = ASPEED_SPI_DEFAULT_FREQ;
> +
> + aspi->num_cs++;
> + }
SPI MEM already gives you all this information. Get it from there, don't
parse it yourself.
You can get Chip Select via spi_mem->spi->chip_select.
You can get clock frequency via spi_mem->spi->max_speed_hz.
With these comments fixed,
Acked-by: Pratyush Yadav <p.yadav@ti.com>
> +
> + return 0;
> +}
> +
[...]
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-25 7:50 ` Pratyush Yadav
0 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 7:50 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> This SPI driver adds support for the Aspeed static memory controllers
> of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
>
> * AST2600 Firmware SPI Memory Controller (FMC)
> . BMC firmware
> . 3 chip select pins (CE0 ~ CE2)
> . Only supports SPI type flash memory
> . different segment register interface
> . single, dual and quad mode.
>
> * AST2600 SPI Flash Controller (SPI1 and SPI2)
> . host firmware
> . 2 chip select pins (CE0 ~ CE1)
> . different segment register interface
> . single, dual and quad mode.
>
> * AST2500 Firmware SPI Memory Controller (FMC)
> . BMC firmware
> . 3 chip select pins (CE0 ~ CE2)
> . supports SPI type flash memory (CE0-CE1)
> . CE2 can be of NOR type flash but this is not supported by the driver
> . single, dual mode.
>
> * AST2500 SPI Flash Controller (SPI1 and SPI2)
> . host firmware
> . 2 chip select pins (CE0 ~ CE1)
> . single, dual mode.
>
> * AST2400 New Static Memory Controller (also referred as FMC)
> . BMC firmware
> . New register set
> . 5 chip select pins (CE0 ∼ CE4)
> . supports NOR flash, NAND flash and SPI flash memory.
> . single, dual and quad mode.
>
> Each controller has a memory range on which flash devices contents are
> mapped. Each device is assigned a window that can be changed at bootime
> with the Segment Address Registers.
>
> Each SPI flash device can then be accessed in two modes: Command and
> User. When in User mode, SPI transfers are initiated with accesses to
> the memory segment of a device. When in Command mode, memory
> operations on the memory segment of a device generate SPI commands
> automatically using a Control Register for the settings.
>
> This initial patch adds support for User mode. Command mode needs a little
> more work to check that the memory window on the AHB bus fits the device
> size. It will come later when support for direct mapping is added.
>
> Single and dual mode RX transfers are supported. Other types than SPI
> are not supported.
>
> Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> drivers/spi/spi-aspeed-smc.c | 766 ++++++++++++++++++++++++
> drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> 4 files changed, 779 insertions(+), 1 deletion(-)
> create mode 100644 drivers/spi/spi-aspeed-smc.c
>
[...]
> +
> +/* support for 1-1-1, 1-1-2 or 1-1-4 */
> +static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
> +{
> + if (op->cmd.buswidth > 1)
> + return false;
> +
> + if (op->addr.nbytes != 0) {
> + if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
> + return false;
> + }
> +
> + if (op->dummy.nbytes != 0) {
> + if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
> + return false;
> + }
> +
> + if (op->data.nbytes != 0 && op->data.buswidth > 4)
> + return false;
> +
> + if (!spi_mem_default_supports_op(mem, op))
> + return false;
> +
> + return true;
Nitpick: You can just do return spi_mem_default_supports_op(mem, op);
> +}
> +
[...]
> +
> +static int aspeed_spi_init_devices(struct platform_device *pdev, struct aspeed_spi *aspi)
> +{
> + struct device_node *np;
> + unsigned int cs;
> + int ret;
> +
> + for_each_available_child_of_node(aspi->dev->of_node, np) {
> + struct aspeed_spi_chip *chip;
> +
> + if (!of_device_is_compatible(np, "jedec,spi-nor"))
> + continue;
> +
> + ret = of_property_read_u32(np, "reg", &cs);
> + if (ret) {
> + dev_err(aspi->dev, "Couldn't not read chip select.\n");
> + of_node_put(np);
> + return ret;
> + }
> +
> + if (cs > aspi->data->max_cs) {
> + dev_err(aspi->dev, "Chip select %d out of range.\n", cs);
> + of_node_put(np);
> + return -ERANGE;
> + }
> +
> + chip = &aspi->chips[cs];
> + chip->aspi = aspi;
> + chip->cs = cs;
> +
> + ret = aspeed_spi_chip_init(chip);
> + if (ret) {
> + of_node_put(np);
> + return ret;
> + }
> +
> + if (of_property_read_u32(np, "spi-max-frequency", &chip->clk_freq))
> + chip->clk_freq = ASPEED_SPI_DEFAULT_FREQ;
> +
> + aspi->num_cs++;
> + }
SPI MEM already gives you all this information. Get it from there, don't
parse it yourself.
You can get Chip Select via spi_mem->spi->chip_select.
You can get clock frequency via spi_mem->spi->max_speed_hz.
With these comments fixed,
Acked-by: Pratyush Yadav <p.yadav@ti.com>
> +
> + return 0;
> +}
> +
[...]
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
_______________________________________________
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] 115+ messages in thread
* Re: [PATCH 04/10] spi: aspeed: Add support for direct mapping
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-25 9:12 ` Pratyush Yadav
-1 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 9:12 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> Use direct mapping to read the flash device contents. This operation
> mode is called "Command mode" on Aspeed SoC SMC controllers. It uses a
> Control Register for the settings to apply when a memory operation is
> performed on the flash device mapping window.
>
> If the window is not big enough, fall back to the "User mode" to
> perform the read.
>
> Direct mapping for writes will come later when validated.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> drivers/spi/spi-aspeed-smc.c | 67 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
> index 0aeff6f468af..8d33fcb7736a 100644
> --- a/drivers/spi/spi-aspeed-smc.c
> +++ b/drivers/spi/spi-aspeed-smc.c
> @@ -345,8 +345,8 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
> if (!op->addr.nbytes)
> ret = aspeed_spi_read_reg(chip, op);
> else
> - ret = aspeed_spi_read_user(chip, op, op->addr.val,
> - op->data.nbytes, op->data.buf.in);
> + memcpy_fromio(op->data.buf.in, chip->ahb_base + op->addr.val,
> + op->data.nbytes);
Why change this? exec_op should be independent from dirmap APIs. And you
don't even do the ahb_window_size checks here.
> } else {
> if (!op->addr.nbytes)
> ret = aspeed_spi_write_reg(chip, op);
> @@ -426,10 +426,73 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
> return chip->ahb_window_size ? 0 : -1;
> }
>
> +static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
> +{
> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
> + struct spi_mem_op *op = &desc->info.op_tmpl;
> + u32 ctl_val;
> + int ret = 0;
> +
> + chip->clk_freq = desc->mem->spi->max_speed_hz;
> +
> + /* Only for reads */
> + if (op->data.dir != SPI_MEM_DATA_IN)
> + return -EOPNOTSUPP;
> +
> + if (desc->info.length > chip->ahb_window_size)
> + dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
> + chip->cs, chip->ahb_window_size >> 20);
> +
> + /* Define the default IO read settings */
> + ctl_val = readl(chip->ctl) & ~CTRL_IO_CMD_MASK;
> + ctl_val |= aspeed_spi_get_io_mode(op) |
> + op->cmd.opcode << CTRL_COMMAND_SHIFT |
> + CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth) |
> + CTRL_IO_MODE_READ;
> +
> + /* Tune 4BYTE address mode */
> + if (op->addr.nbytes) {
> + u32 addr_mode = readl(aspi->regs + CE_CTRL_REG);
> +
> + if (op->addr.nbytes == 4)
> + addr_mode |= (0x11 << chip->cs);
> + else
> + addr_mode &= ~(0x11 << chip->cs);
> + writel(addr_mode, aspi->regs + CE_CTRL_REG);
> + }
> +
> + /* READ mode is the controller default setting */
> + chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
> + writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
> +
> + dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
> + chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
> +
> + return ret;
> +}
> +
> +static int aspeed_spi_dirmap_read(struct spi_mem_dirmap_desc *desc,
> + u64 offset, size_t len, void *buf)
> +{
> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
> +
> + /* Switch to USER command mode if mapping window is too small */
> + if (chip->ahb_window_size < offset + len)
> + aspeed_spi_read_user(chip, &desc->info.op_tmpl, offset, len, buf);
> + else
> + memcpy_fromio(buf, chip->ahb_base + offset, len);
> +
> + return len;
> +}
> +
> static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
> .supports_op = aspeed_spi_supports_op,
> .exec_op = aspeed_spi_exec_op,
> .get_name = aspeed_spi_get_name,
> + .dirmap_create = aspeed_spi_dirmap_create,
> + .dirmap_read = aspeed_spi_dirmap_read,
> };
>
> static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
> --
> 2.34.1
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 04/10] spi: aspeed: Add support for direct mapping
@ 2022-02-25 9:12 ` Pratyush Yadav
0 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 9:12 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> Use direct mapping to read the flash device contents. This operation
> mode is called "Command mode" on Aspeed SoC SMC controllers. It uses a
> Control Register for the settings to apply when a memory operation is
> performed on the flash device mapping window.
>
> If the window is not big enough, fall back to the "User mode" to
> perform the read.
>
> Direct mapping for writes will come later when validated.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> drivers/spi/spi-aspeed-smc.c | 67 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
> index 0aeff6f468af..8d33fcb7736a 100644
> --- a/drivers/spi/spi-aspeed-smc.c
> +++ b/drivers/spi/spi-aspeed-smc.c
> @@ -345,8 +345,8 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
> if (!op->addr.nbytes)
> ret = aspeed_spi_read_reg(chip, op);
> else
> - ret = aspeed_spi_read_user(chip, op, op->addr.val,
> - op->data.nbytes, op->data.buf.in);
> + memcpy_fromio(op->data.buf.in, chip->ahb_base + op->addr.val,
> + op->data.nbytes);
Why change this? exec_op should be independent from dirmap APIs. And you
don't even do the ahb_window_size checks here.
> } else {
> if (!op->addr.nbytes)
> ret = aspeed_spi_write_reg(chip, op);
> @@ -426,10 +426,73 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
> return chip->ahb_window_size ? 0 : -1;
> }
>
> +static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
> +{
> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
> + struct spi_mem_op *op = &desc->info.op_tmpl;
> + u32 ctl_val;
> + int ret = 0;
> +
> + chip->clk_freq = desc->mem->spi->max_speed_hz;
> +
> + /* Only for reads */
> + if (op->data.dir != SPI_MEM_DATA_IN)
> + return -EOPNOTSUPP;
> +
> + if (desc->info.length > chip->ahb_window_size)
> + dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
> + chip->cs, chip->ahb_window_size >> 20);
> +
> + /* Define the default IO read settings */
> + ctl_val = readl(chip->ctl) & ~CTRL_IO_CMD_MASK;
> + ctl_val |= aspeed_spi_get_io_mode(op) |
> + op->cmd.opcode << CTRL_COMMAND_SHIFT |
> + CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth) |
> + CTRL_IO_MODE_READ;
> +
> + /* Tune 4BYTE address mode */
> + if (op->addr.nbytes) {
> + u32 addr_mode = readl(aspi->regs + CE_CTRL_REG);
> +
> + if (op->addr.nbytes == 4)
> + addr_mode |= (0x11 << chip->cs);
> + else
> + addr_mode &= ~(0x11 << chip->cs);
> + writel(addr_mode, aspi->regs + CE_CTRL_REG);
> + }
> +
> + /* READ mode is the controller default setting */
> + chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
> + writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
> +
> + dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
> + chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
> +
> + return ret;
> +}
> +
> +static int aspeed_spi_dirmap_read(struct spi_mem_dirmap_desc *desc,
> + u64 offset, size_t len, void *buf)
> +{
> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
> +
> + /* Switch to USER command mode if mapping window is too small */
> + if (chip->ahb_window_size < offset + len)
> + aspeed_spi_read_user(chip, &desc->info.op_tmpl, offset, len, buf);
> + else
> + memcpy_fromio(buf, chip->ahb_base + offset, len);
> +
> + return len;
> +}
> +
> static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
> .supports_op = aspeed_spi_supports_op,
> .exec_op = aspeed_spi_exec_op,
> .get_name = aspeed_spi_get_name,
> + .dirmap_create = aspeed_spi_dirmap_create,
> + .dirmap_read = aspeed_spi_dirmap_read,
> };
>
> static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
> --
> 2.34.1
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 04/10] spi: aspeed: Add support for direct mapping
@ 2022-02-25 9:12 ` Pratyush Yadav
0 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 9:12 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> Use direct mapping to read the flash device contents. This operation
> mode is called "Command mode" on Aspeed SoC SMC controllers. It uses a
> Control Register for the settings to apply when a memory operation is
> performed on the flash device mapping window.
>
> If the window is not big enough, fall back to the "User mode" to
> perform the read.
>
> Direct mapping for writes will come later when validated.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> drivers/spi/spi-aspeed-smc.c | 67 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
> index 0aeff6f468af..8d33fcb7736a 100644
> --- a/drivers/spi/spi-aspeed-smc.c
> +++ b/drivers/spi/spi-aspeed-smc.c
> @@ -345,8 +345,8 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
> if (!op->addr.nbytes)
> ret = aspeed_spi_read_reg(chip, op);
> else
> - ret = aspeed_spi_read_user(chip, op, op->addr.val,
> - op->data.nbytes, op->data.buf.in);
> + memcpy_fromio(op->data.buf.in, chip->ahb_base + op->addr.val,
> + op->data.nbytes);
Why change this? exec_op should be independent from dirmap APIs. And you
don't even do the ahb_window_size checks here.
> } else {
> if (!op->addr.nbytes)
> ret = aspeed_spi_write_reg(chip, op);
> @@ -426,10 +426,73 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
> return chip->ahb_window_size ? 0 : -1;
> }
>
> +static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
> +{
> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
> + struct spi_mem_op *op = &desc->info.op_tmpl;
> + u32 ctl_val;
> + int ret = 0;
> +
> + chip->clk_freq = desc->mem->spi->max_speed_hz;
> +
> + /* Only for reads */
> + if (op->data.dir != SPI_MEM_DATA_IN)
> + return -EOPNOTSUPP;
> +
> + if (desc->info.length > chip->ahb_window_size)
> + dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
> + chip->cs, chip->ahb_window_size >> 20);
> +
> + /* Define the default IO read settings */
> + ctl_val = readl(chip->ctl) & ~CTRL_IO_CMD_MASK;
> + ctl_val |= aspeed_spi_get_io_mode(op) |
> + op->cmd.opcode << CTRL_COMMAND_SHIFT |
> + CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth) |
> + CTRL_IO_MODE_READ;
> +
> + /* Tune 4BYTE address mode */
> + if (op->addr.nbytes) {
> + u32 addr_mode = readl(aspi->regs + CE_CTRL_REG);
> +
> + if (op->addr.nbytes == 4)
> + addr_mode |= (0x11 << chip->cs);
> + else
> + addr_mode &= ~(0x11 << chip->cs);
> + writel(addr_mode, aspi->regs + CE_CTRL_REG);
> + }
> +
> + /* READ mode is the controller default setting */
> + chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
> + writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
> +
> + dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
> + chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
> +
> + return ret;
> +}
> +
> +static int aspeed_spi_dirmap_read(struct spi_mem_dirmap_desc *desc,
> + u64 offset, size_t len, void *buf)
> +{
> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
> +
> + /* Switch to USER command mode if mapping window is too small */
> + if (chip->ahb_window_size < offset + len)
> + aspeed_spi_read_user(chip, &desc->info.op_tmpl, offset, len, buf);
> + else
> + memcpy_fromio(buf, chip->ahb_base + offset, len);
> +
> + return len;
> +}
> +
> static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
> .supports_op = aspeed_spi_supports_op,
> .exec_op = aspeed_spi_exec_op,
> .get_name = aspeed_spi_get_name,
> + .dirmap_create = aspeed_spi_dirmap_create,
> + .dirmap_read = aspeed_spi_dirmap_read,
> };
>
> static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
> --
> 2.34.1
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
_______________________________________________
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] 115+ messages in thread
* Re: [PATCH 08/10] spi: aspeed: Calibrate read timings
2022-02-14 9:42 ` Cédric Le Goater
(?)
@ 2022-02-25 9:18 ` Pratyush Yadav
-1 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 9:18 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> To accommodate the different response time of SPI transfers on different
> boards and different SPI NOR devices, the Aspeed controllers provide a
> set of Read Timing Compensation registers to tune the timing delays
> depending on the frequency being used. The AST2600 SoC has one of
> these registers per device. On the AST2500 and AST2400 SoCs, the
> timing register is shared by all devices which is a bit problematic to
> get good results other than for one device.
>
> The algorithm first reads a golden buffer at low speed and then performs
> reads with different clocks and delay cycle settings to find a breaking
> point. This selects a default good frequency for the CEx control register.
> The current settings are bit optimistic as we pick the first delay giving
> good results. A safer approach would be to determine an interval and
> choose the middle value.
>
> Due to the lack of API, calibration is performed when the direct mapping
> for reads is created.
The dirmap_create mapping says nothing about _when_ it should be called.
So there is no guarantee that it will only be called after the flash is
fully initialized. I suggest you either make this a requirement of the
API, or create a new API that guarantees it will only be called after
the flash is initialized, like [0].
[0] https://patchwork.ozlabs.org/project/linux-mtd/patch/20210311191216.7363-2-p.yadav@ti.com/
>
> Cc: Pratyush Yadav <p.yadav@ti.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 08/10] spi: aspeed: Calibrate read timings
@ 2022-02-25 9:18 ` Pratyush Yadav
0 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 9:18 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> To accommodate the different response time of SPI transfers on different
> boards and different SPI NOR devices, the Aspeed controllers provide a
> set of Read Timing Compensation registers to tune the timing delays
> depending on the frequency being used. The AST2600 SoC has one of
> these registers per device. On the AST2500 and AST2400 SoCs, the
> timing register is shared by all devices which is a bit problematic to
> get good results other than for one device.
>
> The algorithm first reads a golden buffer at low speed and then performs
> reads with different clocks and delay cycle settings to find a breaking
> point. This selects a default good frequency for the CEx control register.
> The current settings are bit optimistic as we pick the first delay giving
> good results. A safer approach would be to determine an interval and
> choose the middle value.
>
> Due to the lack of API, calibration is performed when the direct mapping
> for reads is created.
The dirmap_create mapping says nothing about _when_ it should be called.
So there is no guarantee that it will only be called after the flash is
fully initialized. I suggest you either make this a requirement of the
API, or create a new API that guarantees it will only be called after
the flash is initialized, like [0].
[0] https://patchwork.ozlabs.org/project/linux-mtd/patch/20210311191216.7363-2-p.yadav@ti.com/
>
> Cc: Pratyush Yadav <p.yadav@ti.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 08/10] spi: aspeed: Calibrate read timings
@ 2022-02-25 9:18 ` Pratyush Yadav
0 siblings, 0 replies; 115+ messages in thread
From: Pratyush Yadav @ 2022-02-25 9:18 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 14/02/22 10:42AM, Cédric Le Goater wrote:
> To accommodate the different response time of SPI transfers on different
> boards and different SPI NOR devices, the Aspeed controllers provide a
> set of Read Timing Compensation registers to tune the timing delays
> depending on the frequency being used. The AST2600 SoC has one of
> these registers per device. On the AST2500 and AST2400 SoCs, the
> timing register is shared by all devices which is a bit problematic to
> get good results other than for one device.
>
> The algorithm first reads a golden buffer at low speed and then performs
> reads with different clocks and delay cycle settings to find a breaking
> point. This selects a default good frequency for the CEx control register.
> The current settings are bit optimistic as we pick the first delay giving
> good results. A safer approach would be to determine an interval and
> choose the middle value.
>
> Due to the lack of API, calibration is performed when the direct mapping
> for reads is created.
The dirmap_create mapping says nothing about _when_ it should be called.
So there is no guarantee that it will only be called after the flash is
fully initialized. I suggest you either make this a requirement of the
API, or create a new API that guarantees it will only be called after
the flash is initialized, like [0].
[0] https://patchwork.ozlabs.org/project/linux-mtd/patch/20210311191216.7363-2-p.yadav@ti.com/
>
> Cc: Pratyush Yadav <p.yadav@ti.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
_______________________________________________
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] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
2022-02-25 7:50 ` Pratyush Yadav
(?)
@ 2022-02-27 18:46 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 18:46 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 08:50, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> This SPI driver adds support for the Aspeed static memory controllers
>> of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
>>
>> * AST2600 Firmware SPI Memory Controller (FMC)
>> . BMC firmware
>> . 3 chip select pins (CE0 ~ CE2)
>> . Only supports SPI type flash memory
>> . different segment register interface
>> . single, dual and quad mode.
>>
>> * AST2600 SPI Flash Controller (SPI1 and SPI2)
>> . host firmware
>> . 2 chip select pins (CE0 ~ CE1)
>> . different segment register interface
>> . single, dual and quad mode.
>>
>> * AST2500 Firmware SPI Memory Controller (FMC)
>> . BMC firmware
>> . 3 chip select pins (CE0 ~ CE2)
>> . supports SPI type flash memory (CE0-CE1)
>> . CE2 can be of NOR type flash but this is not supported by the driver
>> . single, dual mode.
>>
>> * AST2500 SPI Flash Controller (SPI1 and SPI2)
>> . host firmware
>> . 2 chip select pins (CE0 ~ CE1)
>> . single, dual mode.
>>
>> * AST2400 New Static Memory Controller (also referred as FMC)
>> . BMC firmware
>> . New register set
>> . 5 chip select pins (CE0 ∼ CE4)
>> . supports NOR flash, NAND flash and SPI flash memory.
>> . single, dual and quad mode.
>>
>> Each controller has a memory range on which flash devices contents are
>> mapped. Each device is assigned a window that can be changed at bootime
>> with the Segment Address Registers.
>>
>> Each SPI flash device can then be accessed in two modes: Command and
>> User. When in User mode, SPI transfers are initiated with accesses to
>> the memory segment of a device. When in Command mode, memory
>> operations on the memory segment of a device generate SPI commands
>> automatically using a Control Register for the settings.
>>
>> This initial patch adds support for User mode. Command mode needs a little
>> more work to check that the memory window on the AHB bus fits the device
>> size. It will come later when support for direct mapping is added.
>>
>> Single and dual mode RX transfers are supported. Other types than SPI
>> are not supported.
>>
>> Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/spi/spi-aspeed-smc.c | 766 ++++++++++++++++++++++++
>> drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
>> drivers/spi/Kconfig | 11 +
>> drivers/spi/Makefile | 1 +
>> 4 files changed, 779 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/spi/spi-aspeed-smc.c
>>
> [...]
>> +
>> +/* support for 1-1-1, 1-1-2 or 1-1-4 */
>> +static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
>> +{
>> + if (op->cmd.buswidth > 1)
>> + return false;
>> +
>> + if (op->addr.nbytes != 0) {
>> + if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
>> + return false;
>> + }
>> +
>> + if (op->dummy.nbytes != 0) {
>> + if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
>> + return false;
>> + }
>> +
>> + if (op->data.nbytes != 0 && op->data.buswidth > 4)
>> + return false;
>> +
>> + if (!spi_mem_default_supports_op(mem, op))
>> + return false;
>> +
>> + return true;
>
> Nitpick: You can just do return spi_mem_default_supports_op(mem, op);
>
>> +}
>> +
> [...]
>> +
>> +static int aspeed_spi_init_devices(struct platform_device *pdev, struct aspeed_spi *aspi)
>> +{
>> + struct device_node *np;
>> + unsigned int cs;
>> + int ret;
>> +
>> + for_each_available_child_of_node(aspi->dev->of_node, np) {
>> + struct aspeed_spi_chip *chip;
>> +
>> + if (!of_device_is_compatible(np, "jedec,spi-nor"))
>> + continue;
>> +
>> + ret = of_property_read_u32(np, "reg", &cs);
>> + if (ret) {
>> + dev_err(aspi->dev, "Couldn't not read chip select.\n");
>> + of_node_put(np);
>> + return ret;
>> + }
>> +
>> + if (cs > aspi->data->max_cs) {
>> + dev_err(aspi->dev, "Chip select %d out of range.\n", cs);
>> + of_node_put(np);
>> + return -ERANGE;
>> + }
>> +
>> + chip = &aspi->chips[cs];
>> + chip->aspi = aspi;
>> + chip->cs = cs;
>> +
>> + ret = aspeed_spi_chip_init(chip);
>> + if (ret) {
>> + of_node_put(np);
>> + return ret;
>> + }
>> +
>> + if (of_property_read_u32(np, "spi-max-frequency", &chip->clk_freq))
>> + chip->clk_freq = ASPEED_SPI_DEFAULT_FREQ;
>> +
>> + aspi->num_cs++;
>> + }
>
> SPI MEM already gives you all this information. Get it from there, don't
> parse it yourself.
I agree for spi-max-frequency". It's even redundant with the setting
done in :
[PATCH 04/10] spi: aspeed: Add support for direct mapping
> You can get Chip Select via spi_mem->spi->chip_select.
yes but we are still in the probing sequence and some initial settings
need to be done for each device before accessing them. See routine
aspeed_spi_chip_init().
I think a spi setup hook could do that. I will change in v2.
> You can get clock frequency via spi_mem->spi->max_speed_hz.
>
> With these comments fixed,
>
> Acked-by: Pratyush Yadav <p.yadav@ti.com>
Please recheck v2.
Thanks,
C.
>
>> +
>> + return 0;
>> +}
>> +
> [...]
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-27 18:46 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 18:46 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 08:50, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> This SPI driver adds support for the Aspeed static memory controllers
>> of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
>>
>> * AST2600 Firmware SPI Memory Controller (FMC)
>> . BMC firmware
>> . 3 chip select pins (CE0 ~ CE2)
>> . Only supports SPI type flash memory
>> . different segment register interface
>> . single, dual and quad mode.
>>
>> * AST2600 SPI Flash Controller (SPI1 and SPI2)
>> . host firmware
>> . 2 chip select pins (CE0 ~ CE1)
>> . different segment register interface
>> . single, dual and quad mode.
>>
>> * AST2500 Firmware SPI Memory Controller (FMC)
>> . BMC firmware
>> . 3 chip select pins (CE0 ~ CE2)
>> . supports SPI type flash memory (CE0-CE1)
>> . CE2 can be of NOR type flash but this is not supported by the driver
>> . single, dual mode.
>>
>> * AST2500 SPI Flash Controller (SPI1 and SPI2)
>> . host firmware
>> . 2 chip select pins (CE0 ~ CE1)
>> . single, dual mode.
>>
>> * AST2400 New Static Memory Controller (also referred as FMC)
>> . BMC firmware
>> . New register set
>> . 5 chip select pins (CE0 ∼ CE4)
>> . supports NOR flash, NAND flash and SPI flash memory.
>> . single, dual and quad mode.
>>
>> Each controller has a memory range on which flash devices contents are
>> mapped. Each device is assigned a window that can be changed at bootime
>> with the Segment Address Registers.
>>
>> Each SPI flash device can then be accessed in two modes: Command and
>> User. When in User mode, SPI transfers are initiated with accesses to
>> the memory segment of a device. When in Command mode, memory
>> operations on the memory segment of a device generate SPI commands
>> automatically using a Control Register for the settings.
>>
>> This initial patch adds support for User mode. Command mode needs a little
>> more work to check that the memory window on the AHB bus fits the device
>> size. It will come later when support for direct mapping is added.
>>
>> Single and dual mode RX transfers are supported. Other types than SPI
>> are not supported.
>>
>> Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/spi/spi-aspeed-smc.c | 766 ++++++++++++++++++++++++
>> drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
>> drivers/spi/Kconfig | 11 +
>> drivers/spi/Makefile | 1 +
>> 4 files changed, 779 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/spi/spi-aspeed-smc.c
>>
> [...]
>> +
>> +/* support for 1-1-1, 1-1-2 or 1-1-4 */
>> +static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
>> +{
>> + if (op->cmd.buswidth > 1)
>> + return false;
>> +
>> + if (op->addr.nbytes != 0) {
>> + if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
>> + return false;
>> + }
>> +
>> + if (op->dummy.nbytes != 0) {
>> + if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
>> + return false;
>> + }
>> +
>> + if (op->data.nbytes != 0 && op->data.buswidth > 4)
>> + return false;
>> +
>> + if (!spi_mem_default_supports_op(mem, op))
>> + return false;
>> +
>> + return true;
>
> Nitpick: You can just do return spi_mem_default_supports_op(mem, op);
>
>> +}
>> +
> [...]
>> +
>> +static int aspeed_spi_init_devices(struct platform_device *pdev, struct aspeed_spi *aspi)
>> +{
>> + struct device_node *np;
>> + unsigned int cs;
>> + int ret;
>> +
>> + for_each_available_child_of_node(aspi->dev->of_node, np) {
>> + struct aspeed_spi_chip *chip;
>> +
>> + if (!of_device_is_compatible(np, "jedec,spi-nor"))
>> + continue;
>> +
>> + ret = of_property_read_u32(np, "reg", &cs);
>> + if (ret) {
>> + dev_err(aspi->dev, "Couldn't not read chip select.\n");
>> + of_node_put(np);
>> + return ret;
>> + }
>> +
>> + if (cs > aspi->data->max_cs) {
>> + dev_err(aspi->dev, "Chip select %d out of range.\n", cs);
>> + of_node_put(np);
>> + return -ERANGE;
>> + }
>> +
>> + chip = &aspi->chips[cs];
>> + chip->aspi = aspi;
>> + chip->cs = cs;
>> +
>> + ret = aspeed_spi_chip_init(chip);
>> + if (ret) {
>> + of_node_put(np);
>> + return ret;
>> + }
>> +
>> + if (of_property_read_u32(np, "spi-max-frequency", &chip->clk_freq))
>> + chip->clk_freq = ASPEED_SPI_DEFAULT_FREQ;
>> +
>> + aspi->num_cs++;
>> + }
>
> SPI MEM already gives you all this information. Get it from there, don't
> parse it yourself.
I agree for spi-max-frequency". It's even redundant with the setting
done in :
[PATCH 04/10] spi: aspeed: Add support for direct mapping
> You can get Chip Select via spi_mem->spi->chip_select.
yes but we are still in the probing sequence and some initial settings
need to be done for each device before accessing them. See routine
aspeed_spi_chip_init().
I think a spi setup hook could do that. I will change in v2.
> You can get clock frequency via spi_mem->spi->max_speed_hz.
>
> With these comments fixed,
>
> Acked-by: Pratyush Yadav <p.yadav@ti.com>
Please recheck v2.
Thanks,
C.
>
>> +
>> + return 0;
>> +}
>> +
> [...]
>
_______________________________________________
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] 115+ messages in thread
* Re: [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers
@ 2022-02-27 18:46 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 18:46 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 08:50, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> This SPI driver adds support for the Aspeed static memory controllers
>> of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
>>
>> * AST2600 Firmware SPI Memory Controller (FMC)
>> . BMC firmware
>> . 3 chip select pins (CE0 ~ CE2)
>> . Only supports SPI type flash memory
>> . different segment register interface
>> . single, dual and quad mode.
>>
>> * AST2600 SPI Flash Controller (SPI1 and SPI2)
>> . host firmware
>> . 2 chip select pins (CE0 ~ CE1)
>> . different segment register interface
>> . single, dual and quad mode.
>>
>> * AST2500 Firmware SPI Memory Controller (FMC)
>> . BMC firmware
>> . 3 chip select pins (CE0 ~ CE2)
>> . supports SPI type flash memory (CE0-CE1)
>> . CE2 can be of NOR type flash but this is not supported by the driver
>> . single, dual mode.
>>
>> * AST2500 SPI Flash Controller (SPI1 and SPI2)
>> . host firmware
>> . 2 chip select pins (CE0 ~ CE1)
>> . single, dual mode.
>>
>> * AST2400 New Static Memory Controller (also referred as FMC)
>> . BMC firmware
>> . New register set
>> . 5 chip select pins (CE0 ∼ CE4)
>> . supports NOR flash, NAND flash and SPI flash memory.
>> . single, dual and quad mode.
>>
>> Each controller has a memory range on which flash devices contents are
>> mapped. Each device is assigned a window that can be changed at bootime
>> with the Segment Address Registers.
>>
>> Each SPI flash device can then be accessed in two modes: Command and
>> User. When in User mode, SPI transfers are initiated with accesses to
>> the memory segment of a device. When in Command mode, memory
>> operations on the memory segment of a device generate SPI commands
>> automatically using a Control Register for the settings.
>>
>> This initial patch adds support for User mode. Command mode needs a little
>> more work to check that the memory window on the AHB bus fits the device
>> size. It will come later when support for direct mapping is added.
>>
>> Single and dual mode RX transfers are supported. Other types than SPI
>> are not supported.
>>
>> Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/spi/spi-aspeed-smc.c | 766 ++++++++++++++++++++++++
>> drivers/mtd/spi-nor/controllers/Kconfig | 2 +-
>> drivers/spi/Kconfig | 11 +
>> drivers/spi/Makefile | 1 +
>> 4 files changed, 779 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/spi/spi-aspeed-smc.c
>>
> [...]
>> +
>> +/* support for 1-1-1, 1-1-2 or 1-1-4 */
>> +static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
>> +{
>> + if (op->cmd.buswidth > 1)
>> + return false;
>> +
>> + if (op->addr.nbytes != 0) {
>> + if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
>> + return false;
>> + }
>> +
>> + if (op->dummy.nbytes != 0) {
>> + if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
>> + return false;
>> + }
>> +
>> + if (op->data.nbytes != 0 && op->data.buswidth > 4)
>> + return false;
>> +
>> + if (!spi_mem_default_supports_op(mem, op))
>> + return false;
>> +
>> + return true;
>
> Nitpick: You can just do return spi_mem_default_supports_op(mem, op);
>
>> +}
>> +
> [...]
>> +
>> +static int aspeed_spi_init_devices(struct platform_device *pdev, struct aspeed_spi *aspi)
>> +{
>> + struct device_node *np;
>> + unsigned int cs;
>> + int ret;
>> +
>> + for_each_available_child_of_node(aspi->dev->of_node, np) {
>> + struct aspeed_spi_chip *chip;
>> +
>> + if (!of_device_is_compatible(np, "jedec,spi-nor"))
>> + continue;
>> +
>> + ret = of_property_read_u32(np, "reg", &cs);
>> + if (ret) {
>> + dev_err(aspi->dev, "Couldn't not read chip select.\n");
>> + of_node_put(np);
>> + return ret;
>> + }
>> +
>> + if (cs > aspi->data->max_cs) {
>> + dev_err(aspi->dev, "Chip select %d out of range.\n", cs);
>> + of_node_put(np);
>> + return -ERANGE;
>> + }
>> +
>> + chip = &aspi->chips[cs];
>> + chip->aspi = aspi;
>> + chip->cs = cs;
>> +
>> + ret = aspeed_spi_chip_init(chip);
>> + if (ret) {
>> + of_node_put(np);
>> + return ret;
>> + }
>> +
>> + if (of_property_read_u32(np, "spi-max-frequency", &chip->clk_freq))
>> + chip->clk_freq = ASPEED_SPI_DEFAULT_FREQ;
>> +
>> + aspi->num_cs++;
>> + }
>
> SPI MEM already gives you all this information. Get it from there, don't
> parse it yourself.
I agree for spi-max-frequency". It's even redundant with the setting
done in :
[PATCH 04/10] spi: aspeed: Add support for direct mapping
> You can get Chip Select via spi_mem->spi->chip_select.
yes but we are still in the probing sequence and some initial settings
need to be done for each device before accessing them. See routine
aspeed_spi_chip_init().
I think a spi setup hook could do that. I will change in v2.
> You can get clock frequency via spi_mem->spi->max_speed_hz.
>
> With these comments fixed,
>
> Acked-by: Pratyush Yadav <p.yadav@ti.com>
Please recheck v2.
Thanks,
C.
>
>> +
>> + return 0;
>> +}
>> +
> [...]
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
2022-02-25 7:31 ` Pratyush Yadav
(?)
@ 2022-02-27 18:50 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 18:50 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 08:31, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> To prepare transition to the new Aspeed SMC SPI controller driver using
>> the spi-mem interface, change the kernel CONFIG option of the current
>> driver to reflect that the implementation uses the MTD SPI-NOR interface.
>> Once the new driver is sufficiently exposed, we should remove the old one.
>
> I don't quite understand the reasoning behind this. Why keep the old
> driver around? Why not directly replace it with the new one? Does the
> new one have any limitations that this one doesn't?
No. The old one has more limitations than the new one. The old one in
mainline is half baked since we could never merge the necessary bits
for training. We have been keeping a full version on the OpenBMC tree.
Joel, could we simply drop the old driver in mainline and keep the old
one in the OpenBMC tree until we feel comfortable ? I guess we need
more testing.
Thanks,
C.
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-27 18:50 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 18:50 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 08:31, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> To prepare transition to the new Aspeed SMC SPI controller driver using
>> the spi-mem interface, change the kernel CONFIG option of the current
>> driver to reflect that the implementation uses the MTD SPI-NOR interface.
>> Once the new driver is sufficiently exposed, we should remove the old one.
>
> I don't quite understand the reasoning behind this. Why keep the old
> driver around? Why not directly replace it with the new one? Does the
> new one have any limitations that this one doesn't?
No. The old one has more limitations than the new one. The old one in
mainline is half baked since we could never merge the necessary bits
for training. We have been keeping a full version on the OpenBMC tree.
Joel, could we simply drop the old driver in mainline and keep the old
one in the OpenBMC tree until we feel comfortable ? I guess we need
more testing.
Thanks,
C.
>
_______________________________________________
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] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-27 18:50 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 18:50 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 08:31, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> To prepare transition to the new Aspeed SMC SPI controller driver using
>> the spi-mem interface, change the kernel CONFIG option of the current
>> driver to reflect that the implementation uses the MTD SPI-NOR interface.
>> Once the new driver is sufficiently exposed, we should remove the old one.
>
> I don't quite understand the reasoning behind this. Why keep the old
> driver around? Why not directly replace it with the new one? Does the
> new one have any limitations that this one doesn't?
No. The old one has more limitations than the new one. The old one in
mainline is half baked since we could never merge the necessary bits
for training. We have been keeping a full version on the OpenBMC tree.
Joel, could we simply drop the old driver in mainline and keep the old
one in the OpenBMC tree until we feel comfortable ? I guess we need
more testing.
Thanks,
C.
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-02-25 5:29 ` Call for testing: spi-mem " Joel Stanley
@ 2022-02-27 18:53 ` Cédric Le Goater
2022-02-28 6:30 ` Tao Ren
2022-03-02 6:05 ` Tao Ren
2022-03-01 9:57 ` John Wang
1 sibling, 2 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 18:53 UTC (permalink / raw)
To: Joel Stanley, OpenBMC Maillist; +Cc: Lei Yu, Ryan Chen
On 2/25/22 06:29, Joel Stanley wrote:
> Cedric has authored a new drive for the SPI NOR devices on the ASPEED
> SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
> subsystem, which should mean it can go upstream.
>
> This is great news, as our current driver is half upstream, half in
> the openbmc tree, due to some issues getting it merged as part of the
> spi-nor subsystem.
>
> It would be great to have testing. I've created a commit that patches
> in support to whatever kernel tree you're using. Hopefully this makes
> it easier to test atop your internal branches:
>
> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
>
> Cherry pick this commit into your tree, and see how it goes, and report back.
>
> I plan to switch the openbmc tree to this driver when we next rebase
> the kernel. We could also backport it to dev-5.15 as an option.
>
> You can direct testing results to this thread, or reply directly to
> the upstream thread:
>
> https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
or grab the v2 from :
https://github.com/legoater/linux/tree/openbmc-5.15
I have addressed the comments on driver bind/unbind.
Thanks,
C.
>
> Cheers,
>
> Joel
>
> ---------- Forwarded message ---------
> From: Cédric Le Goater <clg@kaod.org>
> Date: Mon, 14 Feb 2022 at 09:42
> Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
> To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
> Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
> <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
> Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
> <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
> <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
> Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
> <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
> Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
> <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
>
>
> Hi,
>
> This series adds a new SPI driver using the spi-mem interface for the
> Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> SoCs.
>
> * AST2600 Firmware SPI Memory Controller (FMC)
> * AST2600 SPI Flash Controller (SPI1 and SPI2)
> * AST2500 Firmware SPI Memory Controller (FMC)
> * AST2500 SPI Flash Controller (SPI1 and SPI2)
> * AST2400 New Static Memory Controller (also referred as FMC)
> * AST2400 SPI Flash Controller (SPI)
>
> It is based on the current OpenBMC kernel driver [1], using directly
> the MTD SPI-NOR interface and on a patchset [2] previously proposed
> adding support for the AST2600 only. This driver takes a slightly
> different approach to cover all 6 controllers.
>
> It does not make use of the controller register disabling Address and
> Data byte lanes because is not available on the AST2400 SoC. We could
> introduce a specific handler for new features available on recent SoCs
> if needed. As there is not much difference on performance, the driver
> chooses the common denominator: "User mode" which has been heavily
> tested in [1]. "User mode" is also used as a fall back method when
> flash device mapping window is too small.
>
> Problems to address with spi-mem were the configuration of the mapping
> windows and the calibration of the read timings. The driver handles
> them in the direct mapping handler when some knowledge on the size of
> the flash device is know. It is not perfect but not incorrect either.
> The algorithm is one from [1] because it doesn't require the DMA
> registers which are not available on all controllers.
>
> Direct mapping for writes is not supported (yet). I have seen some
> corruption with writes and I preferred to use the safer and proven
> method of the initial driver [1]. We can improve that later.
>
> The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> didn't have the expected results. Therefore it is not activated yet.
> This needs more tests.
>
> The series does not remove the current Aspeed SMC driver but prepares
> ground for its removal by changing its CONFIG option. This last step
> can be addressed as a followup when the new driver using the spi-mem
> interface has been sufficiently exposed.
>
> Tested on:
>
> * OpenPOWER Palmetto (AST2400)
> * Evaluation board (AST2500)
> * OpenPOWER Witherspoon (AST2500)
> * Evaluation board (AST2600 A0)
> * Rainier board (AST2600)
>
> [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
>
> Thanks,
>
> C.
>
> Cédric Le Goater (10):
> mtd: spi-nor: aspeed: Rename Kconfig option
> dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> spi: spi-mem: Add driver for Aspeed SMC controllers
> spi: aspeed: Add support for direct mapping
> spi: aspeed: Adjust direct mapping to device size
> spi: aspeed: Workaround AST2500 limitations
> spi: aspeed: Add support for the AST2400 SPI controller
> spi: aspeed: Calibrate read timings
> ARM: dts: aspeed: Enable Dual SPI RX transfers
> spi: aspeed: Activate new spi-mem driver
>
> drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> 9 files changed, 1369 insertions(+), 3 deletions(-)
> create mode 100644 drivers/spi/spi-aspeed-smc.c
> create mode 100644
> Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>
> --
> 2.34.1
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 04/10] spi: aspeed: Add support for direct mapping
2022-02-25 9:12 ` Pratyush Yadav
(?)
@ 2022-02-27 21:06 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 21:06 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 10:12, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> Use direct mapping to read the flash device contents. This operation
>> mode is called "Command mode" on Aspeed SoC SMC controllers. It uses a
>> Control Register for the settings to apply when a memory operation is
>> performed on the flash device mapping window.
>>
>> If the window is not big enough, fall back to the "User mode" to
>> perform the read.
>>
>> Direct mapping for writes will come later when validated.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/spi/spi-aspeed-smc.c | 67 ++++++++++++++++++++++++++++++++++--
>> 1 file changed, 65 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
>> index 0aeff6f468af..8d33fcb7736a 100644
>> --- a/drivers/spi/spi-aspeed-smc.c
>> +++ b/drivers/spi/spi-aspeed-smc.c
>> @@ -345,8 +345,8 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
>> if (!op->addr.nbytes)
>> ret = aspeed_spi_read_reg(chip, op);
>> else
>> - ret = aspeed_spi_read_user(chip, op, op->addr.val,
>> - op->data.nbytes, op->data.buf.in);
>> + memcpy_fromio(op->data.buf.in, chip->ahb_base + op->addr.val,
>> + op->data.nbytes);
>
> Why change this? exec_op should be independent from dirmap APIs. And you
> don't even do the ahb_window_size checks here.
no indeed. Now that direct map is configured, all reads of flash contents
should go through the direct map op. This is mostly for the RDSFDP command
which has a different address space and uses 3B.
Theoretically, we should be able to use memcpy_fromio() and memcpy_toio()
for all commands but not all controllers (6 of them) support this mode.
Thanks,
C.
>
>> } else {
>> if (!op->addr.nbytes)
>> ret = aspeed_spi_write_reg(chip, op);
>> @@ -426,10 +426,73 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
>> return chip->ahb_window_size ? 0 : -1;
>> }
>>
>> +static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
>> +{
>> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
>> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
>> + struct spi_mem_op *op = &desc->info.op_tmpl;
>> + u32 ctl_val;
>> + int ret = 0;
>> +
>> + chip->clk_freq = desc->mem->spi->max_speed_hz;
>> +
>> + /* Only for reads */
>> + if (op->data.dir != SPI_MEM_DATA_IN)
>> + return -EOPNOTSUPP;
>> +
>> + if (desc->info.length > chip->ahb_window_size)
>> + dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
>> + chip->cs, chip->ahb_window_size >> 20);
>> +
>> + /* Define the default IO read settings */
>> + ctl_val = readl(chip->ctl) & ~CTRL_IO_CMD_MASK;
>> + ctl_val |= aspeed_spi_get_io_mode(op) |
>> + op->cmd.opcode << CTRL_COMMAND_SHIFT |
>> + CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth) |
>> + CTRL_IO_MODE_READ;
>> +
>> + /* Tune 4BYTE address mode */
>> + if (op->addr.nbytes) {
>> + u32 addr_mode = readl(aspi->regs + CE_CTRL_REG);
>> +
>> + if (op->addr.nbytes == 4)
>> + addr_mode |= (0x11 << chip->cs);
>> + else
>> + addr_mode &= ~(0x11 << chip->cs);
>> + writel(addr_mode, aspi->regs + CE_CTRL_REG);
>> + }
>> +
>> + /* READ mode is the controller default setting */
>> + chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
>> + writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
>> +
>> + dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
>> + chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
>> +
>> + return ret;
>> +}
>> +
>> +static int aspeed_spi_dirmap_read(struct spi_mem_dirmap_desc *desc,
>> + u64 offset, size_t len, void *buf)
>> +{
>> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
>> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
>> +
>> + /* Switch to USER command mode if mapping window is too small */
>> + if (chip->ahb_window_size < offset + len)
>> + aspeed_spi_read_user(chip, &desc->info.op_tmpl, offset, len, buf);
>> + else
>> + memcpy_fromio(buf, chip->ahb_base + offset, len);
>> +
>> + return len;
>> +}
>> +
>> static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
>> .supports_op = aspeed_spi_supports_op,
>> .exec_op = aspeed_spi_exec_op,
>> .get_name = aspeed_spi_get_name,
>> + .dirmap_create = aspeed_spi_dirmap_create,
>> + .dirmap_read = aspeed_spi_dirmap_read,
>> };
>>
>> static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
>> --
>> 2.34.1
>>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 04/10] spi: aspeed: Add support for direct mapping
@ 2022-02-27 21:06 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 21:06 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 10:12, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> Use direct mapping to read the flash device contents. This operation
>> mode is called "Command mode" on Aspeed SoC SMC controllers. It uses a
>> Control Register for the settings to apply when a memory operation is
>> performed on the flash device mapping window.
>>
>> If the window is not big enough, fall back to the "User mode" to
>> perform the read.
>>
>> Direct mapping for writes will come later when validated.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/spi/spi-aspeed-smc.c | 67 ++++++++++++++++++++++++++++++++++--
>> 1 file changed, 65 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
>> index 0aeff6f468af..8d33fcb7736a 100644
>> --- a/drivers/spi/spi-aspeed-smc.c
>> +++ b/drivers/spi/spi-aspeed-smc.c
>> @@ -345,8 +345,8 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
>> if (!op->addr.nbytes)
>> ret = aspeed_spi_read_reg(chip, op);
>> else
>> - ret = aspeed_spi_read_user(chip, op, op->addr.val,
>> - op->data.nbytes, op->data.buf.in);
>> + memcpy_fromio(op->data.buf.in, chip->ahb_base + op->addr.val,
>> + op->data.nbytes);
>
> Why change this? exec_op should be independent from dirmap APIs. And you
> don't even do the ahb_window_size checks here.
no indeed. Now that direct map is configured, all reads of flash contents
should go through the direct map op. This is mostly for the RDSFDP command
which has a different address space and uses 3B.
Theoretically, we should be able to use memcpy_fromio() and memcpy_toio()
for all commands but not all controllers (6 of them) support this mode.
Thanks,
C.
>
>> } else {
>> if (!op->addr.nbytes)
>> ret = aspeed_spi_write_reg(chip, op);
>> @@ -426,10 +426,73 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
>> return chip->ahb_window_size ? 0 : -1;
>> }
>>
>> +static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
>> +{
>> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
>> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
>> + struct spi_mem_op *op = &desc->info.op_tmpl;
>> + u32 ctl_val;
>> + int ret = 0;
>> +
>> + chip->clk_freq = desc->mem->spi->max_speed_hz;
>> +
>> + /* Only for reads */
>> + if (op->data.dir != SPI_MEM_DATA_IN)
>> + return -EOPNOTSUPP;
>> +
>> + if (desc->info.length > chip->ahb_window_size)
>> + dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
>> + chip->cs, chip->ahb_window_size >> 20);
>> +
>> + /* Define the default IO read settings */
>> + ctl_val = readl(chip->ctl) & ~CTRL_IO_CMD_MASK;
>> + ctl_val |= aspeed_spi_get_io_mode(op) |
>> + op->cmd.opcode << CTRL_COMMAND_SHIFT |
>> + CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth) |
>> + CTRL_IO_MODE_READ;
>> +
>> + /* Tune 4BYTE address mode */
>> + if (op->addr.nbytes) {
>> + u32 addr_mode = readl(aspi->regs + CE_CTRL_REG);
>> +
>> + if (op->addr.nbytes == 4)
>> + addr_mode |= (0x11 << chip->cs);
>> + else
>> + addr_mode &= ~(0x11 << chip->cs);
>> + writel(addr_mode, aspi->regs + CE_CTRL_REG);
>> + }
>> +
>> + /* READ mode is the controller default setting */
>> + chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
>> + writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
>> +
>> + dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
>> + chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
>> +
>> + return ret;
>> +}
>> +
>> +static int aspeed_spi_dirmap_read(struct spi_mem_dirmap_desc *desc,
>> + u64 offset, size_t len, void *buf)
>> +{
>> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
>> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
>> +
>> + /* Switch to USER command mode if mapping window is too small */
>> + if (chip->ahb_window_size < offset + len)
>> + aspeed_spi_read_user(chip, &desc->info.op_tmpl, offset, len, buf);
>> + else
>> + memcpy_fromio(buf, chip->ahb_base + offset, len);
>> +
>> + return len;
>> +}
>> +
>> static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
>> .supports_op = aspeed_spi_supports_op,
>> .exec_op = aspeed_spi_exec_op,
>> .get_name = aspeed_spi_get_name,
>> + .dirmap_create = aspeed_spi_dirmap_create,
>> + .dirmap_read = aspeed_spi_dirmap_read,
>> };
>>
>> static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
>> --
>> 2.34.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] 115+ messages in thread
* Re: [PATCH 04/10] spi: aspeed: Add support for direct mapping
@ 2022-02-27 21:06 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 21:06 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 10:12, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> Use direct mapping to read the flash device contents. This operation
>> mode is called "Command mode" on Aspeed SoC SMC controllers. It uses a
>> Control Register for the settings to apply when a memory operation is
>> performed on the flash device mapping window.
>>
>> If the window is not big enough, fall back to the "User mode" to
>> perform the read.
>>
>> Direct mapping for writes will come later when validated.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/spi/spi-aspeed-smc.c | 67 ++++++++++++++++++++++++++++++++++--
>> 1 file changed, 65 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
>> index 0aeff6f468af..8d33fcb7736a 100644
>> --- a/drivers/spi/spi-aspeed-smc.c
>> +++ b/drivers/spi/spi-aspeed-smc.c
>> @@ -345,8 +345,8 @@ static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o
>> if (!op->addr.nbytes)
>> ret = aspeed_spi_read_reg(chip, op);
>> else
>> - ret = aspeed_spi_read_user(chip, op, op->addr.val,
>> - op->data.nbytes, op->data.buf.in);
>> + memcpy_fromio(op->data.buf.in, chip->ahb_base + op->addr.val,
>> + op->data.nbytes);
>
> Why change this? exec_op should be independent from dirmap APIs. And you
> don't even do the ahb_window_size checks here.
no indeed. Now that direct map is configured, all reads of flash contents
should go through the direct map op. This is mostly for the RDSFDP command
which has a different address space and uses 3B.
Theoretically, we should be able to use memcpy_fromio() and memcpy_toio()
for all commands but not all controllers (6 of them) support this mode.
Thanks,
C.
>
>> } else {
>> if (!op->addr.nbytes)
>> ret = aspeed_spi_write_reg(chip, op);
>> @@ -426,10 +426,73 @@ static int aspeed_spi_chip_set_default_window(struct aspeed_spi_chip *chip)
>> return chip->ahb_window_size ? 0 : -1;
>> }
>>
>> +static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
>> +{
>> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
>> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
>> + struct spi_mem_op *op = &desc->info.op_tmpl;
>> + u32 ctl_val;
>> + int ret = 0;
>> +
>> + chip->clk_freq = desc->mem->spi->max_speed_hz;
>> +
>> + /* Only for reads */
>> + if (op->data.dir != SPI_MEM_DATA_IN)
>> + return -EOPNOTSUPP;
>> +
>> + if (desc->info.length > chip->ahb_window_size)
>> + dev_warn(aspi->dev, "CE%d window (%dMB) too small for mapping",
>> + chip->cs, chip->ahb_window_size >> 20);
>> +
>> + /* Define the default IO read settings */
>> + ctl_val = readl(chip->ctl) & ~CTRL_IO_CMD_MASK;
>> + ctl_val |= aspeed_spi_get_io_mode(op) |
>> + op->cmd.opcode << CTRL_COMMAND_SHIFT |
>> + CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth) |
>> + CTRL_IO_MODE_READ;
>> +
>> + /* Tune 4BYTE address mode */
>> + if (op->addr.nbytes) {
>> + u32 addr_mode = readl(aspi->regs + CE_CTRL_REG);
>> +
>> + if (op->addr.nbytes == 4)
>> + addr_mode |= (0x11 << chip->cs);
>> + else
>> + addr_mode &= ~(0x11 << chip->cs);
>> + writel(addr_mode, aspi->regs + CE_CTRL_REG);
>> + }
>> +
>> + /* READ mode is the controller default setting */
>> + chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
>> + writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
>> +
>> + dev_info(aspi->dev, "CE%d read buswidth:%d [0x%08x]\n",
>> + chip->cs, op->data.buswidth, chip->ctl_val[ASPEED_SPI_READ]);
>> +
>> + return ret;
>> +}
>> +
>> +static int aspeed_spi_dirmap_read(struct spi_mem_dirmap_desc *desc,
>> + u64 offset, size_t len, void *buf)
>> +{
>> + struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
>> + struct aspeed_spi_chip *chip = &aspi->chips[desc->mem->spi->chip_select];
>> +
>> + /* Switch to USER command mode if mapping window is too small */
>> + if (chip->ahb_window_size < offset + len)
>> + aspeed_spi_read_user(chip, &desc->info.op_tmpl, offset, len, buf);
>> + else
>> + memcpy_fromio(buf, chip->ahb_base + offset, len);
>> +
>> + return len;
>> +}
>> +
>> static const struct spi_controller_mem_ops aspeed_spi_mem_ops = {
>> .supports_op = aspeed_spi_supports_op,
>> .exec_op = aspeed_spi_exec_op,
>> .get_name = aspeed_spi_get_name,
>> + .dirmap_create = aspeed_spi_dirmap_create,
>> + .dirmap_read = aspeed_spi_dirmap_read,
>> };
>>
>> static void aspeed_spi_chip_set_type(struct aspeed_spi_chip *chip, int type)
>> --
>> 2.34.1
>>
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 08/10] spi: aspeed: Calibrate read timings
2022-02-25 9:18 ` Pratyush Yadav
(?)
@ 2022-02-27 21:27 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 21:27 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 10:18, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> To accommodate the different response time of SPI transfers on different
>> boards and different SPI NOR devices, the Aspeed controllers provide a
>> set of Read Timing Compensation registers to tune the timing delays
>> depending on the frequency being used. The AST2600 SoC has one of
>> these registers per device. On the AST2500 and AST2400 SoCs, the
>> timing register is shared by all devices which is a bit problematic to
>> get good results other than for one device.
>>
>> The algorithm first reads a golden buffer at low speed and then performs
>> reads with different clocks and delay cycle settings to find a breaking
>> point. This selects a default good frequency for the CEx control register.
>> The current settings are bit optimistic as we pick the first delay giving
>> good results. A safer approach would be to determine an interval and
>> choose the middle value.
>>
>> Due to the lack of API, calibration is performed when the direct mapping
>> for reads is created.
>
> The dirmap_create mapping says nothing about _when_ it should be called.
> So there is no guarantee that it will only be called after the flash is
> fully initialized.
spi_nor_create_read_dirmap() is called after spi_nor_scan() in spi_nor_probe().
Since a spi_mem_dirmap_info descriptor is created using the nor fields :
struct spi_mem_dirmap_info info = {
.op_tmpl = SPI_MEM_OP(SPI_MEM_OP_CMD(nor->read_opcode, 0),
SPI_MEM_OP_ADDR(nor->addr_width, 0, 0),
SPI_MEM_OP_DUMMY(nor->read_dummy, 0),
SPI_MEM_OP_DATA_IN(0, NULL, 0)),
.offset = 0,
.length = nor->params->size,
};
struct spi_mem_op *op = &info.op_tmpl;
the spi-mem framework makes the assumption that the nor object is initialized.
> I suggest you either make this a requirement of the API,
how ?
Thanks,
C.
> or create a new API that guarantees it will only be called after
> the flash is initialized, like [0].
>
> [0] https://patchwork.ozlabs.org/project/linux-mtd/patch/20210311191216.7363-2-p.yadav@ti.com/
>
>>
>> Cc: Pratyush Yadav <p.yadav@ti.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 08/10] spi: aspeed: Calibrate read timings
@ 2022-02-27 21:27 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 21:27 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 10:18, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> To accommodate the different response time of SPI transfers on different
>> boards and different SPI NOR devices, the Aspeed controllers provide a
>> set of Read Timing Compensation registers to tune the timing delays
>> depending on the frequency being used. The AST2600 SoC has one of
>> these registers per device. On the AST2500 and AST2400 SoCs, the
>> timing register is shared by all devices which is a bit problematic to
>> get good results other than for one device.
>>
>> The algorithm first reads a golden buffer at low speed and then performs
>> reads with different clocks and delay cycle settings to find a breaking
>> point. This selects a default good frequency for the CEx control register.
>> The current settings are bit optimistic as we pick the first delay giving
>> good results. A safer approach would be to determine an interval and
>> choose the middle value.
>>
>> Due to the lack of API, calibration is performed when the direct mapping
>> for reads is created.
>
> The dirmap_create mapping says nothing about _when_ it should be called.
> So there is no guarantee that it will only be called after the flash is
> fully initialized.
spi_nor_create_read_dirmap() is called after spi_nor_scan() in spi_nor_probe().
Since a spi_mem_dirmap_info descriptor is created using the nor fields :
struct spi_mem_dirmap_info info = {
.op_tmpl = SPI_MEM_OP(SPI_MEM_OP_CMD(nor->read_opcode, 0),
SPI_MEM_OP_ADDR(nor->addr_width, 0, 0),
SPI_MEM_OP_DUMMY(nor->read_dummy, 0),
SPI_MEM_OP_DATA_IN(0, NULL, 0)),
.offset = 0,
.length = nor->params->size,
};
struct spi_mem_op *op = &info.op_tmpl;
the spi-mem framework makes the assumption that the nor object is initialized.
> I suggest you either make this a requirement of the API,
how ?
Thanks,
C.
> or create a new API that guarantees it will only be called after
> the flash is initialized, like [0].
>
> [0] https://patchwork.ozlabs.org/project/linux-mtd/patch/20210311191216.7363-2-p.yadav@ti.com/
>
>>
>> Cc: Pratyush Yadav <p.yadav@ti.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 08/10] spi: aspeed: Calibrate read timings
@ 2022-02-27 21:27 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-27 21:27 UTC (permalink / raw)
To: Pratyush Yadav
Cc: linux-spi, linux-mtd, Mark Brown, Tudor Ambarus, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-aspeed,
Joel Stanley, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, linux-arm-kernel, linux-kernel
On 2/25/22 10:18, Pratyush Yadav wrote:
> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>> To accommodate the different response time of SPI transfers on different
>> boards and different SPI NOR devices, the Aspeed controllers provide a
>> set of Read Timing Compensation registers to tune the timing delays
>> depending on the frequency being used. The AST2600 SoC has one of
>> these registers per device. On the AST2500 and AST2400 SoCs, the
>> timing register is shared by all devices which is a bit problematic to
>> get good results other than for one device.
>>
>> The algorithm first reads a golden buffer at low speed and then performs
>> reads with different clocks and delay cycle settings to find a breaking
>> point. This selects a default good frequency for the CEx control register.
>> The current settings are bit optimistic as we pick the first delay giving
>> good results. A safer approach would be to determine an interval and
>> choose the middle value.
>>
>> Due to the lack of API, calibration is performed when the direct mapping
>> for reads is created.
>
> The dirmap_create mapping says nothing about _when_ it should be called.
> So there is no guarantee that it will only be called after the flash is
> fully initialized.
spi_nor_create_read_dirmap() is called after spi_nor_scan() in spi_nor_probe().
Since a spi_mem_dirmap_info descriptor is created using the nor fields :
struct spi_mem_dirmap_info info = {
.op_tmpl = SPI_MEM_OP(SPI_MEM_OP_CMD(nor->read_opcode, 0),
SPI_MEM_OP_ADDR(nor->addr_width, 0, 0),
SPI_MEM_OP_DUMMY(nor->read_dummy, 0),
SPI_MEM_OP_DATA_IN(0, NULL, 0)),
.offset = 0,
.length = nor->params->size,
};
struct spi_mem_op *op = &info.op_tmpl;
the spi-mem framework makes the assumption that the nor object is initialized.
> I suggest you either make this a requirement of the API,
how ?
Thanks,
C.
> or create a new API that guarantees it will only be called after
> the flash is initialized, like [0].
>
> [0] https://patchwork.ozlabs.org/project/linux-mtd/patch/20210311191216.7363-2-p.yadav@ti.com/
>
>>
>> Cc: Pratyush Yadav <p.yadav@ti.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>
_______________________________________________
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] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
2022-02-27 18:50 ` Cédric Le Goater
(?)
@ 2022-02-28 6:07 ` Joel Stanley
-1 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-28 6:07 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Pratyush Yadav, linux-spi, linux-mtd, Mark Brown, Tudor Ambarus,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Sun, 27 Feb 2022 at 18:50, Cédric Le Goater <clg@kaod.org> wrote:
>
> On 2/25/22 08:31, Pratyush Yadav wrote:
> > On 14/02/22 10:42AM, Cédric Le Goater wrote:
> >> To prepare transition to the new Aspeed SMC SPI controller driver using
> >> the spi-mem interface, change the kernel CONFIG option of the current
> >> driver to reflect that the implementation uses the MTD SPI-NOR interface.
> >> Once the new driver is sufficiently exposed, we should remove the old one.
> >
> > I don't quite understand the reasoning behind this. Why keep the old
> > driver around? Why not directly replace it with the new one? Does the
> > new one have any limitations that this one doesn't?
>
> No. The old one has more limitations than the new one. The old one in
> mainline is half baked since we could never merge the necessary bits
> for training. We have been keeping a full version on the OpenBMC tree.
>
> Joel, could we simply drop the old driver in mainline and keep the old
> one in the OpenBMC tree until we feel comfortable ? I guess we need
> more testing.
I would answer Pratyush's question with: the old one is well tested,
and the new one is not. We would intend to keep the old one around for
a release cycle or two, and once we're confident the new one is stable
we would remove the old.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-28 6:07 ` Joel Stanley
0 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-28 6:07 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Pratyush Yadav, linux-spi, linux-mtd, Mark Brown, Tudor Ambarus,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Sun, 27 Feb 2022 at 18:50, Cédric Le Goater <clg@kaod.org> wrote:
>
> On 2/25/22 08:31, Pratyush Yadav wrote:
> > On 14/02/22 10:42AM, Cédric Le Goater wrote:
> >> To prepare transition to the new Aspeed SMC SPI controller driver using
> >> the spi-mem interface, change the kernel CONFIG option of the current
> >> driver to reflect that the implementation uses the MTD SPI-NOR interface.
> >> Once the new driver is sufficiently exposed, we should remove the old one.
> >
> > I don't quite understand the reasoning behind this. Why keep the old
> > driver around? Why not directly replace it with the new one? Does the
> > new one have any limitations that this one doesn't?
>
> No. The old one has more limitations than the new one. The old one in
> mainline is half baked since we could never merge the necessary bits
> for training. We have been keeping a full version on the OpenBMC tree.
>
> Joel, could we simply drop the old driver in mainline and keep the old
> one in the OpenBMC tree until we feel comfortable ? I guess we need
> more testing.
I would answer Pratyush's question with: the old one is well tested,
and the new one is not. We would intend to keep the old one around for
a release cycle or two, and once we're confident the new one is stable
we would remove the old.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-28 6:07 ` Joel Stanley
0 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-02-28 6:07 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Pratyush Yadav, linux-spi, linux-mtd, Mark Brown, Tudor Ambarus,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On Sun, 27 Feb 2022 at 18:50, Cédric Le Goater <clg@kaod.org> wrote:
>
> On 2/25/22 08:31, Pratyush Yadav wrote:
> > On 14/02/22 10:42AM, Cédric Le Goater wrote:
> >> To prepare transition to the new Aspeed SMC SPI controller driver using
> >> the spi-mem interface, change the kernel CONFIG option of the current
> >> driver to reflect that the implementation uses the MTD SPI-NOR interface.
> >> Once the new driver is sufficiently exposed, we should remove the old one.
> >
> > I don't quite understand the reasoning behind this. Why keep the old
> > driver around? Why not directly replace it with the new one? Does the
> > new one have any limitations that this one doesn't?
>
> No. The old one has more limitations than the new one. The old one in
> mainline is half baked since we could never merge the necessary bits
> for training. We have been keeping a full version on the OpenBMC tree.
>
> Joel, could we simply drop the old driver in mainline and keep the old
> one in the OpenBMC tree until we feel comfortable ? I guess we need
> more testing.
I would answer Pratyush's question with: the old one is well tested,
and the new one is not. We would intend to keep the old one around for
a release cycle or two, and once we're confident the new one is stable
we would remove the old.
_______________________________________________
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] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-02-27 18:53 ` Cédric Le Goater
@ 2022-02-28 6:30 ` Tao Ren
2022-03-02 6:05 ` Tao Ren
1 sibling, 0 replies; 115+ messages in thread
From: Tao Ren @ 2022-02-28 6:30 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen
Thank you Cedric and Joel! I have AST2400, AST2500 and AST2600 OpenBMC
platforms and I can test these patches. It may take a few days as I'm
just back from holiday (need to catch up at work), but I should be able
to share my findings by middle this week.
Cheers,
Tao
On Sun, Feb 27, 2022 at 07:53:37PM +0100, Cédric Le Goater wrote:
> On 2/25/22 06:29, Joel Stanley wrote:
> > Cedric has authored a new drive for the SPI NOR devices on the ASPEED
> > SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
> > subsystem, which should mean it can go upstream.
> >
> > This is great news, as our current driver is half upstream, half in
> > the openbmc tree, due to some issues getting it merged as part of the
> > spi-nor subsystem.
> >
> > It would be great to have testing. I've created a commit that patches
> > in support to whatever kernel tree you're using. Hopefully this makes
> > it easier to test atop your internal branches:
> >
> > https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
> >
> > Cherry pick this commit into your tree, and see how it goes, and report back.
> >
> > I plan to switch the openbmc tree to this driver when we next rebase
> > the kernel. We could also backport it to dev-5.15 as an option.
> >
> > You can direct testing results to this thread, or reply directly to
> > the upstream thread:
> >
> > https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
>
> or grab the v2 from :
>
> https://github.com/legoater/linux/tree/openbmc-5.15
>
> I have addressed the comments on driver bind/unbind.
>
> Thanks,
>
> C.
>
> >
> > Cheers,
> >
> > Joel
> >
> > ---------- Forwarded message ---------
> > From: Cédric Le Goater <clg@kaod.org>
> > Date: Mon, 14 Feb 2022 at 09:42
> > Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
> > To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
> > Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
> > <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
> > Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
> > <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
> > <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
> > Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
> > <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
> > Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
> > <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
> >
> >
> > Hi,
> >
> > This series adds a new SPI driver using the spi-mem interface for the
> > Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> > SoCs.
> >
> > * AST2600 Firmware SPI Memory Controller (FMC)
> > * AST2600 SPI Flash Controller (SPI1 and SPI2)
> > * AST2500 Firmware SPI Memory Controller (FMC)
> > * AST2500 SPI Flash Controller (SPI1 and SPI2)
> > * AST2400 New Static Memory Controller (also referred as FMC)
> > * AST2400 SPI Flash Controller (SPI)
> >
> > It is based on the current OpenBMC kernel driver [1], using directly
> > the MTD SPI-NOR interface and on a patchset [2] previously proposed
> > adding support for the AST2600 only. This driver takes a slightly
> > different approach to cover all 6 controllers.
> >
> > It does not make use of the controller register disabling Address and
> > Data byte lanes because is not available on the AST2400 SoC. We could
> > introduce a specific handler for new features available on recent SoCs
> > if needed. As there is not much difference on performance, the driver
> > chooses the common denominator: "User mode" which has been heavily
> > tested in [1]. "User mode" is also used as a fall back method when
> > flash device mapping window is too small.
> >
> > Problems to address with spi-mem were the configuration of the mapping
> > windows and the calibration of the read timings. The driver handles
> > them in the direct mapping handler when some knowledge on the size of
> > the flash device is know. It is not perfect but not incorrect either.
> > The algorithm is one from [1] because it doesn't require the DMA
> > registers which are not available on all controllers.
> >
> > Direct mapping for writes is not supported (yet). I have seen some
> > corruption with writes and I preferred to use the safer and proven
> > method of the initial driver [1]. We can improve that later.
> >
> > The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> > didn't have the expected results. Therefore it is not activated yet.
> > This needs more tests.
> >
> > The series does not remove the current Aspeed SMC driver but prepares
> > ground for its removal by changing its CONFIG option. This last step
> > can be addressed as a followup when the new driver using the spi-mem
> > interface has been sufficiently exposed.
> >
> > Tested on:
> >
> > * OpenPOWER Palmetto (AST2400)
> > * Evaluation board (AST2500)
> > * OpenPOWER Witherspoon (AST2500)
> > * Evaluation board (AST2600 A0)
> > * Rainier board (AST2600)
> >
> > [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> > [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
> >
> > Thanks,
> >
> > C.
> >
> > Cédric Le Goater (10):
> > mtd: spi-nor: aspeed: Rename Kconfig option
> > dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> > spi: spi-mem: Add driver for Aspeed SMC controllers
> > spi: aspeed: Add support for direct mapping
> > spi: aspeed: Adjust direct mapping to device size
> > spi: aspeed: Workaround AST2500 limitations
> > spi: aspeed: Add support for the AST2400 SPI controller
> > spi: aspeed: Calibrate read timings
> > ARM: dts: aspeed: Enable Dual SPI RX transfers
> > spi: aspeed: Activate new spi-mem driver
> >
> > drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> > .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> > arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> > arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> > arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> > drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> > drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> > drivers/spi/Kconfig | 11 +
> > drivers/spi/Makefile | 1 +
> > 9 files changed, 1369 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/spi/spi-aspeed-smc.c
> > create mode 100644
> > Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> >
> > --
> > 2.34.1
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
2022-02-28 6:07 ` Joel Stanley
(?)
@ 2022-02-28 14:37 ` Cédric Le Goater
-1 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-28 14:37 UTC (permalink / raw)
To: Joel Stanley
Cc: Pratyush Yadav, linux-spi, linux-mtd, Mark Brown, Tudor Ambarus,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On 2/28/22 07:07, Joel Stanley wrote:
> On Sun, 27 Feb 2022 at 18:50, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> On 2/25/22 08:31, Pratyush Yadav wrote:
>>> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>>>> To prepare transition to the new Aspeed SMC SPI controller driver using
>>>> the spi-mem interface, change the kernel CONFIG option of the current
>>>> driver to reflect that the implementation uses the MTD SPI-NOR interface.
>>>> Once the new driver is sufficiently exposed, we should remove the old one.
>>>
>>> I don't quite understand the reasoning behind this. Why keep the old
>>> driver around? Why not directly replace it with the new one? Does the
>>> new one have any limitations that this one doesn't?
>>
>> No. The old one has more limitations than the new one. The old one in
>> mainline is half baked since we could never merge the necessary bits
>> for training. We have been keeping a full version in the OpenBMC tree.
>>
>> Joel, could we simply drop the old driver in mainline and keep the old
>> one in the OpenBMC tree until we feel comfortable ? I guess we need
>> more testing.
>
> I would answer Pratyush's question with: the old one is well tested,
> and the new one is not. We would intend to keep the old one around for
> a release cycle or two, and once we're confident the new one is stable
> we would remove the old.
yes but we could handle the transition in the OpenBMC tree without putting
the burden on mainline.
mainline would only have the newer spi-mem based driver, the OpenBMC tree
would have it also, along with the older SPI-NOR based driver.
So this patch renaming the Kconfig option would only apply to the OpenBMC
tree.
C.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-28 14:37 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-28 14:37 UTC (permalink / raw)
To: Joel Stanley
Cc: Pratyush Yadav, linux-spi, linux-mtd, Mark Brown, Tudor Ambarus,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On 2/28/22 07:07, Joel Stanley wrote:
> On Sun, 27 Feb 2022 at 18:50, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> On 2/25/22 08:31, Pratyush Yadav wrote:
>>> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>>>> To prepare transition to the new Aspeed SMC SPI controller driver using
>>>> the spi-mem interface, change the kernel CONFIG option of the current
>>>> driver to reflect that the implementation uses the MTD SPI-NOR interface.
>>>> Once the new driver is sufficiently exposed, we should remove the old one.
>>>
>>> I don't quite understand the reasoning behind this. Why keep the old
>>> driver around? Why not directly replace it with the new one? Does the
>>> new one have any limitations that this one doesn't?
>>
>> No. The old one has more limitations than the new one. The old one in
>> mainline is half baked since we could never merge the necessary bits
>> for training. We have been keeping a full version in the OpenBMC tree.
>>
>> Joel, could we simply drop the old driver in mainline and keep the old
>> one in the OpenBMC tree until we feel comfortable ? I guess we need
>> more testing.
>
> I would answer Pratyush's question with: the old one is well tested,
> and the new one is not. We would intend to keep the old one around for
> a release cycle or two, and once we're confident the new one is stable
> we would remove the old.
yes but we could handle the transition in the OpenBMC tree without putting
the burden on mainline.
mainline would only have the newer spi-mem based driver, the OpenBMC tree
would have it also, along with the older SPI-NOR based driver.
So this patch renaming the Kconfig option would only apply to the OpenBMC
tree.
C.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option
@ 2022-02-28 14:37 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-02-28 14:37 UTC (permalink / raw)
To: Joel Stanley
Cc: Pratyush Yadav, linux-spi, linux-mtd, Mark Brown, Tudor Ambarus,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
linux-aspeed, Andrew Jeffery, Chin-Ting Kuo, devicetree,
Rob Herring, Linux ARM, Linux Kernel Mailing List
On 2/28/22 07:07, Joel Stanley wrote:
> On Sun, 27 Feb 2022 at 18:50, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> On 2/25/22 08:31, Pratyush Yadav wrote:
>>> On 14/02/22 10:42AM, Cédric Le Goater wrote:
>>>> To prepare transition to the new Aspeed SMC SPI controller driver using
>>>> the spi-mem interface, change the kernel CONFIG option of the current
>>>> driver to reflect that the implementation uses the MTD SPI-NOR interface.
>>>> Once the new driver is sufficiently exposed, we should remove the old one.
>>>
>>> I don't quite understand the reasoning behind this. Why keep the old
>>> driver around? Why not directly replace it with the new one? Does the
>>> new one have any limitations that this one doesn't?
>>
>> No. The old one has more limitations than the new one. The old one in
>> mainline is half baked since we could never merge the necessary bits
>> for training. We have been keeping a full version in the OpenBMC tree.
>>
>> Joel, could we simply drop the old driver in mainline and keep the old
>> one in the OpenBMC tree until we feel comfortable ? I guess we need
>> more testing.
>
> I would answer Pratyush's question with: the old one is well tested,
> and the new one is not. We would intend to keep the old one around for
> a release cycle or two, and once we're confident the new one is stable
> we would remove the old.
yes but we could handle the transition in the OpenBMC tree without putting
the burden on mainline.
mainline would only have the newer spi-mem based driver, the OpenBMC tree
would have it also, along with the older SPI-NOR based driver.
So this patch renaming the Kconfig option would only apply to the OpenBMC
tree.
C.
_______________________________________________
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] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-02-25 5:29 ` Call for testing: spi-mem " Joel Stanley
2022-02-27 18:53 ` Cédric Le Goater
@ 2022-03-01 9:57 ` John Wang
2022-03-01 10:25 ` Cédric Le Goater
2022-03-01 12:20 ` Joel Stanley
1 sibling, 2 replies; 115+ messages in thread
From: John Wang @ 2022-03-01 9:57 UTC (permalink / raw)
To: Joel Stanley; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen, Cédric Le Goater
Joel Stanley <joel@jms.id.au> 于2022年2月25日周五 13:30写道：
>
> Cedric has authored a new drive for the SPI NOR devices on the ASPEED
> SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
> subsystem, which should mean it can go upstream.
>
> This is great news, as our current driver is half upstream, half in
> the openbmc tree, due to some issues getting it merged as part of the
> spi-nor subsystem.
>
> It would be great to have testing. I've created a commit that patches
> in support to whatever kernel tree you're using. Hopefully this makes
> it easier to test atop your internal branches:
>
> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
tested on a fp5280g2 (ast2500), it looks okay.
root@fp5280g2:~# dmesg |grep spi
[ 1.594677] spi-nor spi0.0: mx66l51235f (65536 Kbytes)
[ 1.728194] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
[ 1.992733] spi-nor spi1.0: mx66l51235f (65536 Kbytes)
[ 2.211741] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
[ 3.175017] SPI driver bmp280 has no spi_device_id for bosch,bmp085
>
> Cherry pick this commit into your tree, and see how it goes, and report back.
>
> I plan to switch the openbmc tree to this driver when we next rebase
> the kernel. We could also backport it to dev-5.15 as an option.
>
> You can direct testing results to this thread, or reply directly to
> the upstream thread:
>
> https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
>
> Cheers,
>
> Joel
>
> ---------- Forwarded message ---------
> From: Cédric Le Goater <clg@kaod.org>
> Date: Mon, 14 Feb 2022 at 09:42
> Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
> To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
> Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
> <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
> Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
> <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
> <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
> Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
> <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
> Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
> <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
>
>
> Hi,
>
> This series adds a new SPI driver using the spi-mem interface for the
> Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> SoCs.
>
> * AST2600 Firmware SPI Memory Controller (FMC)
> * AST2600 SPI Flash Controller (SPI1 and SPI2)
> * AST2500 Firmware SPI Memory Controller (FMC)
> * AST2500 SPI Flash Controller (SPI1 and SPI2)
> * AST2400 New Static Memory Controller (also referred as FMC)
> * AST2400 SPI Flash Controller (SPI)
>
> It is based on the current OpenBMC kernel driver [1], using directly
> the MTD SPI-NOR interface and on a patchset [2] previously proposed
> adding support for the AST2600 only. This driver takes a slightly
> different approach to cover all 6 controllers.
>
> It does not make use of the controller register disabling Address and
> Data byte lanes because is not available on the AST2400 SoC. We could
> introduce a specific handler for new features available on recent SoCs
> if needed. As there is not much difference on performance, the driver
> chooses the common denominator: "User mode" which has been heavily
> tested in [1]. "User mode" is also used as a fall back method when
> flash device mapping window is too small.
>
> Problems to address with spi-mem were the configuration of the mapping
> windows and the calibration of the read timings. The driver handles
> them in the direct mapping handler when some knowledge on the size of
> the flash device is know. It is not perfect but not incorrect either.
> The algorithm is one from [1] because it doesn't require the DMA
> registers which are not available on all controllers.
>
> Direct mapping for writes is not supported (yet). I have seen some
> corruption with writes and I preferred to use the safer and proven
> method of the initial driver [1]. We can improve that later.
>
> The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> didn't have the expected results. Therefore it is not activated yet.
> This needs more tests.
>
> The series does not remove the current Aspeed SMC driver but prepares
> ground for its removal by changing its CONFIG option. This last step
> can be addressed as a followup when the new driver using the spi-mem
> interface has been sufficiently exposed.
>
> Tested on:
>
> * OpenPOWER Palmetto (AST2400)
> * Evaluation board (AST2500)
> * OpenPOWER Witherspoon (AST2500)
> * Evaluation board (AST2600 A0)
> * Rainier board (AST2600)
>
> [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
>
> Thanks,
>
> C.
>
> Cédric Le Goater (10):
> mtd: spi-nor: aspeed: Rename Kconfig option
> dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> spi: spi-mem: Add driver for Aspeed SMC controllers
> spi: aspeed: Add support for direct mapping
> spi: aspeed: Adjust direct mapping to device size
> spi: aspeed: Workaround AST2500 limitations
> spi: aspeed: Add support for the AST2400 SPI controller
> spi: aspeed: Calibrate read timings
> ARM: dts: aspeed: Enable Dual SPI RX transfers
> spi: aspeed: Activate new spi-mem driver
>
> drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> 9 files changed, 1369 insertions(+), 3 deletions(-)
> create mode 100644 drivers/spi/spi-aspeed-smc.c
> create mode 100644
> Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>
> --
> 2.34.1
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-01 9:57 ` John Wang
@ 2022-03-01 10:25 ` Cédric Le Goater
2022-03-02 2:47 ` John Wang
2022-03-01 12:20 ` Joel Stanley
1 sibling, 1 reply; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-01 10:25 UTC (permalink / raw)
To: John Wang, Joel Stanley; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen
On 3/1/22 10:57, John Wang wrote:
> Joel Stanley <joel@jms.id.au> 于2022年2月25日周五 13:30写道：
>>
>> Cedric has authored a new drive for the SPI NOR devices on the ASPEED
>> SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
>> subsystem, which should mean it can go upstream.
>>
>> This is great news, as our current driver is half upstream, half in
>> the openbmc tree, due to some issues getting it merged as part of the
>> spi-nor subsystem.
>>
>> It would be great to have testing. I've created a commit that patches
>> in support to whatever kernel tree you're using. Hopefully this makes
>> it easier to test atop your internal branches:
>>
>> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
>
> tested on a fp5280g2 (ast2500), it looks okay.
Thanks !
> root@fp5280g2:~# dmesg |grep spi
> [ 1.594677] spi-nor spi0.0: mx66l51235f (65536 Kbytes)
> [ 1.728194] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> [ 1.992733] spi-nor spi1.0: mx66l51235f (65536 Kbytes)
> [ 2.211741] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
Training was done on both controllers. It's a little faster on SPI1 because
the clock is set at KCLK/2 whereas FMC uses HCLK/4. Dual IO 4B read command
is the default setting for both.
I test writing with :
dd if=/dev/random of=$tmp bs=1M count=$count
md5sum $tmp
time flashcp -v $tmp $mtd # ~3min for 32MB
time md5sum $mtd # ~3s for 32MB
but not on /dev/mtd0 !
C.
> [ 3.175017] SPI driver bmp280 has no spi_device_id for bosch,bmp085
>
>
>
>>
>> Cherry pick this commit into your tree, and see how it goes, and report back.
>>
>> I plan to switch the openbmc tree to this driver when we next rebase
>> the kernel. We could also backport it to dev-5.15 as an option.
>>
>> You can direct testing results to this thread, or reply directly to
>> the upstream thread:
>>
>> https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
>>
>> Cheers,
>>
>> Joel
>>
>> ---------- Forwarded message ---------
>> From: Cédric Le Goater <clg@kaod.org>
>> Date: Mon, 14 Feb 2022 at 09:42
>> Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
>> To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
>> Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
>> <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
>> Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
>> <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
>> <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
>> Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
>> <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
>> Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
>> <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
>>
>>
>> Hi,
>>
>> This series adds a new SPI driver using the spi-mem interface for the
>> Aspeed static memory controllers of the AST2600, AST2500 and AST2400
>> SoCs.
>>
>> * AST2600 Firmware SPI Memory Controller (FMC)
>> * AST2600 SPI Flash Controller (SPI1 and SPI2)
>> * AST2500 Firmware SPI Memory Controller (FMC)
>> * AST2500 SPI Flash Controller (SPI1 and SPI2)
>> * AST2400 New Static Memory Controller (also referred as FMC)
>> * AST2400 SPI Flash Controller (SPI)
>>
>> It is based on the current OpenBMC kernel driver [1], using directly
>> the MTD SPI-NOR interface and on a patchset [2] previously proposed
>> adding support for the AST2600 only. This driver takes a slightly
>> different approach to cover all 6 controllers.
>>
>> It does not make use of the controller register disabling Address and
>> Data byte lanes because is not available on the AST2400 SoC. We could
>> introduce a specific handler for new features available on recent SoCs
>> if needed. As there is not much difference on performance, the driver
>> chooses the common denominator: "User mode" which has been heavily
>> tested in [1]. "User mode" is also used as a fall back method when
>> flash device mapping window is too small.
>>
>> Problems to address with spi-mem were the configuration of the mapping
>> windows and the calibration of the read timings. The driver handles
>> them in the direct mapping handler when some knowledge on the size of
>> the flash device is know. It is not perfect but not incorrect either.
>> The algorithm is one from [1] because it doesn't require the DMA
>> registers which are not available on all controllers.
>>
>> Direct mapping for writes is not supported (yet). I have seen some
>> corruption with writes and I preferred to use the safer and proven
>> method of the initial driver [1]. We can improve that later.
>>
>> The driver supports Quad SPI RX transfers on the AST2600 SoC but it
>> didn't have the expected results. Therefore it is not activated yet.
>> This needs more tests.
>>
>> The series does not remove the current Aspeed SMC driver but prepares
>> ground for its removal by changing its CONFIG option. This last step
>> can be addressed as a followup when the new driver using the spi-mem
>> interface has been sufficiently exposed.
>>
>> Tested on:
>>
>> * OpenPOWER Palmetto (AST2400)
>> * Evaluation board (AST2500)
>> * OpenPOWER Witherspoon (AST2500)
>> * Evaluation board (AST2600 A0)
>> * Rainier board (AST2600)
>>
>> [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
>> [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
>>
>> Thanks,
>>
>> C.
>>
>> Cédric Le Goater (10):
>> mtd: spi-nor: aspeed: Rename Kconfig option
>> dt-bindings: spi: Add Aspeed SMC controllers device tree binding
>> spi: spi-mem: Add driver for Aspeed SMC controllers
>> spi: aspeed: Add support for direct mapping
>> spi: aspeed: Adjust direct mapping to device size
>> spi: aspeed: Workaround AST2500 limitations
>> spi: aspeed: Add support for the AST2400 SPI controller
>> spi: aspeed: Calibrate read timings
>> ARM: dts: aspeed: Enable Dual SPI RX transfers
>> spi: aspeed: Activate new spi-mem driver
>>
>> drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
>> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
>> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
>> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
>> arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
>> drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
>> drivers/mtd/spi-nor/controllers/Makefile | 2 +-
>> drivers/spi/Kconfig | 11 +
>> drivers/spi/Makefile | 1 +
>> 9 files changed, 1369 insertions(+), 3 deletions(-)
>> create mode 100644 drivers/spi/spi-aspeed-smc.c
>> create mode 100644
>> Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>>
>> --
>> 2.34.1
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-01 9:57 ` John Wang
2022-03-01 10:25 ` Cédric Le Goater
@ 2022-03-01 12:20 ` Joel Stanley
2022-03-02 2:28 ` [External] " Lei Yu
2022-03-02 5:45 ` Cédric Le Goater
1 sibling, 2 replies; 115+ messages in thread
From: Joel Stanley @ 2022-03-01 12:20 UTC (permalink / raw)
To: John Wang; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen, Cédric Le Goater
On Tue, 1 Mar 2022 at 09:57, John Wang <wangzq.jn@gmail.com> wrote:
>
> Joel Stanley <joel@jms.id.au> 于2022年2月25日周五 13:30写道：
> >
> > Cedric has authored a new drive for the SPI NOR devices on the ASPEED
> > SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
> > subsystem, which should mean it can go upstream.
> >
> > This is great news, as our current driver is half upstream, half in
> > the openbmc tree, due to some issues getting it merged as part of the
> > spi-nor subsystem.
> >
> > It would be great to have testing. I've created a commit that patches
> > in support to whatever kernel tree you're using. Hopefully this makes
> > it easier to test atop your internal branches:
> >
> > https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
>
> tested on a fp5280g2 (ast2500), it looks okay.
>
> root@fp5280g2:~# dmesg |grep spi
> [ 1.594677] spi-nor spi0.0: mx66l51235f (65536 Kbytes)
> [ 1.728194] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> [ 1.992733] spi-nor spi1.0: mx66l51235f (65536 Kbytes)
> [ 2.211741] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
> [ 3.175017] SPI driver bmp280 has no spi_device_id for bosch,bmp085
I've also done some testing, this time on an AST2600A3 EVB.
I tried to enable quad spi by adjust the device tree:
--- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
@@ -157,10 +157,13 @@ &rtc {
};
&fmc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fwqspid_default>;
status = "okay";
flash@0 {
status = "okay";
m25p,fast-read;
+ spi-rx-bus-width = <4>;
label = "bmc";
spi-max-frequency = <50000000>;
But the pinctrl setting failed with this error:
[ 0.742963] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: invalid
function FWQSPID in map table
So I removed the quad spi settings and re-tested:
[ 0.746796] spi-nor spi0.0: w25q512jv (65536 Kbytes)
[ 0.808104] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
[ 0.862687] spi-nor spi0.1: w25q512jv (65536 Kbytes)
[ 0.923991] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
[ 0.937639] spi-nor spi1.0: w25q256 (32768 Kbytes)
[ 1.062246] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
[ 1.076507] spi-nor spi2.0: gd25q256 (32768 Kbytes)
[ 1.173951] spi-aspeed-smc 1e631000.spi: CE0 read buswidth:2 [0x203c0741]
./mtd-stress.sh mtd5 mtd6 mtd7 mtd8
22+0 records in
22+0 records out
23068672 bytes (23 MB, 22 MiB) copied, 2.40148 s, 9.6 MB/s
14d980eb27e1b5d6554f22a71fc93de6 /tmp/tmp.CWpblJtRYl
Erasing blocks: 352/352 (100%)
Writing data: 22528k/22528k (100%)
Verifying data: 22528k/22528k (100%)
real 2m47.896s
user 0m0.080s
sys 2m46.984s
14d980eb27e1b5d6554f22a71fc93de6 /dev/mtd5
real 0m3.344s
user 0m0.166s
sys 0m3.101s
64+0 records in
64+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 5.38035 s, 12.5 MB/s
5b2a21e51a39f6c4e01c92b3c1b8825c /tmp/tmp.BnJmqVrHHa
Erasing blocks: 1024/1024 (100%)
Writing data: 65536k/65536k (100%)
Verifying data: 65536k/65536k (100%)
real 7m40.625s
user 0m0.230s
sys 7m39.931s
5b2a21e51a39f6c4e01c92b3c1b8825c /dev/mtd6
real 0m9.723s
user 0m0.484s
sys 0m9.110s
32+0 records in
32+0 records out
33554432 bytes (34 MB, 32 MiB) copied, 2.4457 s, 13.7 MB/s
a3a343b1d4233e364d332a9b466a0a40 /tmp/tmp.4NsXyq09Km
Erasing blocks: 512/512 (100%)
Writing data: 32768k/32768k (100%)
Verifying data: 32768k/32768k (100%)
real 2m17.560s
user 0m0.100s
sys 2m17.346s
a3a343b1d4233e364d332a9b466a0a40 /dev/mtd7
real 0m3.598s
user 0m0.247s
sys 0m3.313s
32+0 records in
32+0 records out
33554432 bytes (34 MB, 32 MiB) copied, 3.49483 s, 9.6 MB/s
fc65634b925e4655dd9db70972c1ed46 /tmp/tmp.MaXhJaz10l
Erasing blocks: 512/512 (100%)
Writing data: 32768k/32768k (100%)
Verifying data: 32768k/32768k (100%)
real 1m46.311s
user 0m0.130s
sys 1m46.064s
fc65634b925e4655dd9db70972c1ed46 /dev/mtd8
real 0m3.513s
user 0m0.246s
sys 0m3.219s
>
>
>
> >
> > Cherry pick this commit into your tree, and see how it goes, and report back.
> >
> > I plan to switch the openbmc tree to this driver when we next rebase
> > the kernel. We could also backport it to dev-5.15 as an option.
> >
> > You can direct testing results to this thread, or reply directly to
> > the upstream thread:
> >
> > https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
> >
> > Cheers,
> >
> > Joel
> >
> > ---------- Forwarded message ---------
> > From: Cédric Le Goater <clg@kaod.org>
> > Date: Mon, 14 Feb 2022 at 09:42
> > Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
> > To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
> > Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
> > <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
> > Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
> > <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
> > <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
> > Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
> > <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
> > Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
> > <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
> >
> >
> > Hi,
> >
> > This series adds a new SPI driver using the spi-mem interface for the
> > Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> > SoCs.
> >
> > * AST2600 Firmware SPI Memory Controller (FMC)
> > * AST2600 SPI Flash Controller (SPI1 and SPI2)
> > * AST2500 Firmware SPI Memory Controller (FMC)
> > * AST2500 SPI Flash Controller (SPI1 and SPI2)
> > * AST2400 New Static Memory Controller (also referred as FMC)
> > * AST2400 SPI Flash Controller (SPI)
> >
> > It is based on the current OpenBMC kernel driver [1], using directly
> > the MTD SPI-NOR interface and on a patchset [2] previously proposed
> > adding support for the AST2600 only. This driver takes a slightly
> > different approach to cover all 6 controllers.
> >
> > It does not make use of the controller register disabling Address and
> > Data byte lanes because is not available on the AST2400 SoC. We could
> > introduce a specific handler for new features available on recent SoCs
> > if needed. As there is not much difference on performance, the driver
> > chooses the common denominator: "User mode" which has been heavily
> > tested in [1]. "User mode" is also used as a fall back method when
> > flash device mapping window is too small.
> >
> > Problems to address with spi-mem were the configuration of the mapping
> > windows and the calibration of the read timings. The driver handles
> > them in the direct mapping handler when some knowledge on the size of
> > the flash device is know. It is not perfect but not incorrect either.
> > The algorithm is one from [1] because it doesn't require the DMA
> > registers which are not available on all controllers.
> >
> > Direct mapping for writes is not supported (yet). I have seen some
> > corruption with writes and I preferred to use the safer and proven
> > method of the initial driver [1]. We can improve that later.
> >
> > The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> > didn't have the expected results. Therefore it is not activated yet.
> > This needs more tests.
> >
> > The series does not remove the current Aspeed SMC driver but prepares
> > ground for its removal by changing its CONFIG option. This last step
> > can be addressed as a followup when the new driver using the spi-mem
> > interface has been sufficiently exposed.
> >
> > Tested on:
> >
> > * OpenPOWER Palmetto (AST2400)
> > * Evaluation board (AST2500)
> > * OpenPOWER Witherspoon (AST2500)
> > * Evaluation board (AST2600 A0)
> > * Rainier board (AST2600)
> >
> > [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> > [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
> >
> > Thanks,
> >
> > C.
> >
> > Cédric Le Goater (10):
> > mtd: spi-nor: aspeed: Rename Kconfig option
> > dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> > spi: spi-mem: Add driver for Aspeed SMC controllers
> > spi: aspeed: Add support for direct mapping
> > spi: aspeed: Adjust direct mapping to device size
> > spi: aspeed: Workaround AST2500 limitations
> > spi: aspeed: Add support for the AST2400 SPI controller
> > spi: aspeed: Calibrate read timings
> > ARM: dts: aspeed: Enable Dual SPI RX transfers
> > spi: aspeed: Activate new spi-mem driver
> >
> > drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> > .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> > arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> > arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> > arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> > drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> > drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> > drivers/spi/Kconfig | 11 +
> > drivers/spi/Makefile | 1 +
> > 9 files changed, 1369 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/spi/spi-aspeed-smc.c
> > create mode 100644
> > Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> >
> > --
> > 2.34.1
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [External] Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-01 12:20 ` Joel Stanley
@ 2022-03-02 2:28 ` Lei Yu
2022-03-07 9:41 ` Lei Yu
2022-03-02 5:45 ` Cédric Le Goater
1 sibling, 1 reply; 115+ messages in thread
From: Lei Yu @ 2022-03-02 2:28 UTC (permalink / raw)
To: Joel Stanley
Cc: Ryan Chen, OpenBMC Maillist, John Wang, Cédric Le Goater
> I tried to enable quad spi by adjust the device tree:
>
> --- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> +++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> @@ -157,10 +157,13 @@ &rtc {
> };
>
> &fmc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_fwqspid_default>;
We had similar issue, for QSPI it needs to pick FWQSPI related changes
from aspeed-sdk's tree:
https://github.com/AspeedTech-BMC/linux/blob/aspeed-master-v5.15/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c#L1322
And with the updated dtsi:
https://github.com/AspeedTech-BMC/linux/blob/aspeed-master-v5.15/arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi#L120
And with the machine dts:
pinctrl-0 = <&pinctrl_fwqspi_default>;
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-01 10:25 ` Cédric Le Goater
@ 2022-03-02 2:47 ` John Wang
0 siblings, 0 replies; 115+ messages in thread
From: John Wang @ 2022-03-02 2:47 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen, Joel Stanley
Cédric Le Goater <clg@kaod.org> 于2022年3月1日周二 18:25写道：
>
> On 3/1/22 10:57, John Wang wrote:
> > Joel Stanley <joel@jms.id.au> 于2022年2月25日周五 13:30写道：
> >>
> >> Cedric has authored a new drive for the SPI NOR devices on the ASPEED
> >> SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
> >> subsystem, which should mean it can go upstream.
> >>
> >> This is great news, as our current driver is half upstream, half in
> >> the openbmc tree, due to some issues getting it merged as part of the
> >> spi-nor subsystem.
> >>
> >> It would be great to have testing. I've created a commit that patches
> >> in support to whatever kernel tree you're using. Hopefully this makes
> >> it easier to test atop your internal branches:
> >>
> >> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
> >
> > tested on a fp5280g2 (ast2500), it looks okay.
>
> Thanks !
>
> > root@fp5280g2:~# dmesg |grep spi
> > [ 1.594677] spi-nor spi0.0: mx66l51235f (65536 Kbytes)
> > [ 1.728194] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> > [ 1.992733] spi-nor spi1.0: mx66l51235f (65536 Kbytes)
> > [ 2.211741] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
>
> Training was done on both controllers. It's a little faster on SPI1 because
> the clock is set at KCLK/2 whereas FMC uses HCLK/4. Dual IO 4B read command
> is the default setting for both.
>
> I test writing with :
>
> dd if=/dev/random of=$tmp bs=1M count=$count
> md5sum $tmp
>
> time flashcp -v $tmp $mtd # ~3min for 32MB
> time md5sum $mtd # ~3s for 32MB
>
> but not on /dev/mtd0 !
>
test writing on a 2500 :)
root@fp5280g2:/tmp# time dd if=/dev/random of=/tmp/test bs=1M count=32
32+0 records in
32+0 records out
real 0m3.144s
user 0m0.002s
sys 0m2.278s
root@fp5280g2:/tmp# md5sum /tmp/test
bed6912a0b257cb7acb79f1c7f99cf6e /tmp/test
root@fp5280g2:/tmp# time flashcp -v /tmp/test /dev/mtd4 # 32M
Erasing block: 512/512 (100%)
Writing kb: 32768/32768 (100%)
Verifying kb: 32768/32768 (100%)
real 4m12.713s
user 0m1.878s
sys 2m42.690s
root@fp5280g2:/tmp# time md5sum /dev/mtd4
bed6912a0b257cb7acb79f1c7f99cf6e /dev/mtd4
real 0m7.668s
user 0m0.832s
sys 0m3.524s
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-01 12:20 ` Joel Stanley
2022-03-02 2:28 ` [External] " Lei Yu
@ 2022-03-02 5:45 ` Cédric Le Goater
2022-03-03 9:45 ` Joel Stanley
1 sibling, 1 reply; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-02 5:45 UTC (permalink / raw)
To: Joel Stanley, John Wang; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen
On 3/1/22 13:20, Joel Stanley wrote:
> On Tue, 1 Mar 2022 at 09:57, John Wang <wangzq.jn@gmail.com> wrote:
>>
>> Joel Stanley <joel@jms.id.au> 于2022年2月25日周五 13:30写道：
>>>
>>> Cedric has authored a new drive for the SPI NOR devices on the ASPEED
>>> SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
>>> subsystem, which should mean it can go upstream.
>>>
>>> This is great news, as our current driver is half upstream, half in
>>> the openbmc tree, due to some issues getting it merged as part of the
>>> spi-nor subsystem.
>>>
>>> It would be great to have testing. I've created a commit that patches
>>> in support to whatever kernel tree you're using. Hopefully this makes
>>> it easier to test atop your internal branches:
>>>
>>> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
>>
>> tested on a fp5280g2 (ast2500), it looks okay.
>>
>> root@fp5280g2:~# dmesg |grep spi
>> [ 1.594677] spi-nor spi0.0: mx66l51235f (65536 Kbytes)
>> [ 1.728194] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
>> [ 1.992733] spi-nor spi1.0: mx66l51235f (65536 Kbytes)
>> [ 2.211741] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
>> [ 3.175017] SPI driver bmp280 has no spi_device_id for bosch,bmp085
>
>
> I've also done some testing, this time on an AST2600A3 EVB.
>
> I tried to enable quad spi by adjust the device tree:
>
> --- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> +++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> @@ -157,10 +157,13 @@ &rtc {
> };
>
> &fmc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_fwqspid_default>;
> status = "okay";
> flash@0 {
> status = "okay";
> m25p,fast-read;
> + spi-rx-bus-width = <4>;
> label = "bmc";
> spi-max-frequency = <50000000>;
>
>
> But the pinctrl setting failed with this error:
>
> [ 0.742963] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: invalid
> function FWQSPID in map table
>
> So I removed the quad spi settings and re-tested:
>
> [ 0.746796] spi-nor spi0.0: w25q512jv (65536 Kbytes)
> [ 0.808104] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> [ 0.862687] spi-nor spi0.1: w25q512jv (65536 Kbytes)
> [ 0.923991] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
On the FMC controller, could you please increase the clock to :
spi-max-frequency = <100000000>;
and check the results ?
> [ 0.937639] spi-nor spi1.0: w25q256 (32768 Kbytes)
> [ 1.062246] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
> [ 1.076507] spi-nor spi2.0: gd25q256 (32768 Kbytes)
> [ 1.173951] spi-aspeed-smc 1e631000.spi: CE0 read buswidth:2 [0x203c0741]
>
> ./mtd-stress.sh mtd5 mtd6 mtd7 mtd8
A good test would be to read from /dev/mtd0 and reflash the resulting file.
Keep an external programmer close at hand just in case :)
Thanks for these tests Joel,
C.
> 22+0 records in
> 22+0 records out
> 23068672 bytes (23 MB, 22 MiB) copied, 2.40148 s, 9.6 MB/s
> 14d980eb27e1b5d6554f22a71fc93de6 /tmp/tmp.CWpblJtRYl
> Erasing blocks: 352/352 (100%)
> Writing data: 22528k/22528k (100%)
> Verifying data: 22528k/22528k (100%)
>
> real 2m47.896s
> user 0m0.080s
> sys 2m46.984s
> 14d980eb27e1b5d6554f22a71fc93de6 /dev/mtd5
>
> real 0m3.344s
> user 0m0.166s
> sys 0m3.101s
>
>
> 64+0 records in
> 64+0 records out
> 67108864 bytes (67 MB, 64 MiB) copied, 5.38035 s, 12.5 MB/s
> 5b2a21e51a39f6c4e01c92b3c1b8825c /tmp/tmp.BnJmqVrHHa
> Erasing blocks: 1024/1024 (100%)
> Writing data: 65536k/65536k (100%)
> Verifying data: 65536k/65536k (100%)
>
> real 7m40.625s
> user 0m0.230s
> sys 7m39.931s
> 5b2a21e51a39f6c4e01c92b3c1b8825c /dev/mtd6
>
> real 0m9.723s
> user 0m0.484s
> sys 0m9.110s
>
>
> 32+0 records in
> 32+0 records out
> 33554432 bytes (34 MB, 32 MiB) copied, 2.4457 s, 13.7 MB/s
> a3a343b1d4233e364d332a9b466a0a40 /tmp/tmp.4NsXyq09Km
> Erasing blocks: 512/512 (100%)
> Writing data: 32768k/32768k (100%)
> Verifying data: 32768k/32768k (100%)
>
> real 2m17.560s
> user 0m0.100s
> sys 2m17.346s
> a3a343b1d4233e364d332a9b466a0a40 /dev/mtd7
>
> real 0m3.598s
> user 0m0.247s
> sys 0m3.313s
>
>
> 32+0 records in
> 32+0 records out
> 33554432 bytes (34 MB, 32 MiB) copied, 3.49483 s, 9.6 MB/s
> fc65634b925e4655dd9db70972c1ed46 /tmp/tmp.MaXhJaz10l
> Erasing blocks: 512/512 (100%)
> Writing data: 32768k/32768k (100%)
> Verifying data: 32768k/32768k (100%)
>
> real 1m46.311s
> user 0m0.130s
> sys 1m46.064s
> fc65634b925e4655dd9db70972c1ed46 /dev/mtd8
>
> real 0m3.513s
> user 0m0.246s
> sys 0m3.219s
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-02-27 18:53 ` Cédric Le Goater
2022-02-28 6:30 ` Tao Ren
@ 2022-03-02 6:05 ` Tao Ren
2022-03-02 6:23 ` Cédric Le Goater
1 sibling, 1 reply; 115+ messages in thread
From: Tao Ren @ 2022-03-02 6:05 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen, Joel Stanley
Hi Cedric,
I tested v2 on wedge100 (ast2400) and cmm (ast2500). I don't see any
functional failures except below warning on ast2400. Is it something we
should worry about?
> spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
The v2 patch series (10 patches) were applied to linux stable 5.15.25,
and below are the outputs on wedge100 (ast2400):
root@wedge100-bmc:~# dmesg | grep -i spi
[ 11.479736] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
[ 11.704313] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
[ 11.785842] 5 fixed-partitions partitions found on MTD device spi0.0
[ 11.862033] Creating 5 MTD partitions on "spi0.0":
[ 13.039009] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
[ 13.107056] spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
[ 13.190551] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0041]
[ 13.271959] 1 fixed-partitions partitions found on MTD device spi0.1
[ 13.348097] Creating 1 MTD partitions on "spi0.1":
[ 28.169886] SPI driver bmp280 has no spi_device_id for bosch,bmp085
root@wedge100-bmc:/tmp# cat /proc/mtd
dev: size erasesize name
mtd0: 00060000 00010000 "u-boot"
mtd1: 00020000 00010000 "env"
mtd2: 01b80000 00010000 "fit"
mtd3: 00400000 00010000 "data0"
mtd4: 02000000 00010000 "flash0"
mtd5: 02000000 00010000 "flash1"
root@wedge100-bmc:/tmp# ls -l flash-wedge100
-rw-r--r-- 1 root root 22867574 Mar 1 20:49 flash-wedge100
root@wedge100-bmc:/tmp# time flashcp flash-wedge100 /dev/mtd4
real 2m22.860s
user 0m0.478s
sys 2m10.647s
root@wedge100-bmc:/tmp# ls -l flash-wedge100.v2021.13.1
-rw-r--r-- 1 root root 19743390 Mar 1 10:10 flash-wedge100.v2021.13.1
root@wedge100-bmc:/tmp# time flashcp flash-wedge100.v2021.13.1 /dev/mtd5
real 2m23.144s
user 0m0.409s
sys 2m10.526s
And here are the outpus on cmm (ast2500):
root@cmm001-oob:~# dmesg | grep -i spi
[ 15.172879] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
[ 15.361516] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
[ 15.442978] 5 fixed-partitions partitions found on MTD device spi0.0
[ 15.519145] Creating 5 MTD partitions on "spi0.0":
[ 15.883123] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
[ 16.071286] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
[ 16.152711] 1 fixed-partitions partitions found on MTD device spi0.1
[ 16.228830] Creating 1 MTD partitions on "spi0.1":
[ 63.831721] SPI driver bmp280 has no spi_device_id for bosch,bmp085
root@cmm001-oob:/tmp# cat /proc/mtd
dev: size erasesize name
mtd0: 00060000 00001000 "u-boot"
mtd1: 00020000 00001000 "env"
mtd2: 01b80000 00001000 "fit"
mtd3: 00400000 00001000 "data0"
mtd4: 02000000 00001000 "flash0"
mtd5: 02000000 00001000 "flash1"
root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm
-rw-r--r-- 1 root root 23772278 Mar 1 21:04 /tmp/flash-cmm
root@cmm001-oob:/tmp# time flashcp /tmp/flash-cmm /dev/mtd4
real 3m37.154s
user 0m0.260s
sys 3m31.700s
root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm.v2021.48.0
-rw-r--r-- 1 root root 23723958 Mar 1 21:07 /tmp/flash-cmm.v2021.48.0
root@cmm001-oob:/tmp# time flashcp flash-cmm.v2021.48.0 /dev/mtd5
real 3m33.843s
user 0m0.458s
sys 3m28.216s
Cheers,
Tao
On Sun, Feb 27, 2022 at 07:53:37PM +0100, Cédric Le Goater wrote:
> On 2/25/22 06:29, Joel Stanley wrote:
> > Cedric has authored a new drive for the SPI NOR devices on the ASPEED
> > SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
> > subsystem, which should mean it can go upstream.
> >
> > This is great news, as our current driver is half upstream, half in
> > the openbmc tree, due to some issues getting it merged as part of the
> > spi-nor subsystem.
> >
> > It would be great to have testing. I've created a commit that patches
> > in support to whatever kernel tree you're using. Hopefully this makes
> > it easier to test atop your internal branches:
> >
> > https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
> >
> > Cherry pick this commit into your tree, and see how it goes, and report back.
> >
> > I plan to switch the openbmc tree to this driver when we next rebase
> > the kernel. We could also backport it to dev-5.15 as an option.
> >
> > You can direct testing results to this thread, or reply directly to
> > the upstream thread:
> >
> > https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
>
> or grab the v2 from :
>
> https://github.com/legoater/linux/tree/openbmc-5.15
>
> I have addressed the comments on driver bind/unbind.
>
> Thanks,
>
> C.
>
> >
> > Cheers,
> >
> > Joel
> >
> > ---------- Forwarded message ---------
> > From: Cédric Le Goater <clg@kaod.org>
> > Date: Mon, 14 Feb 2022 at 09:42
> > Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
> > To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
> > Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
> > <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
> > Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
> > <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
> > <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
> > Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
> > <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
> > Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
> > <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
> >
> >
> > Hi,
> >
> > This series adds a new SPI driver using the spi-mem interface for the
> > Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> > SoCs.
> >
> > * AST2600 Firmware SPI Memory Controller (FMC)
> > * AST2600 SPI Flash Controller (SPI1 and SPI2)
> > * AST2500 Firmware SPI Memory Controller (FMC)
> > * AST2500 SPI Flash Controller (SPI1 and SPI2)
> > * AST2400 New Static Memory Controller (also referred as FMC)
> > * AST2400 SPI Flash Controller (SPI)
> >
> > It is based on the current OpenBMC kernel driver [1], using directly
> > the MTD SPI-NOR interface and on a patchset [2] previously proposed
> > adding support for the AST2600 only. This driver takes a slightly
> > different approach to cover all 6 controllers.
> >
> > It does not make use of the controller register disabling Address and
> > Data byte lanes because is not available on the AST2400 SoC. We could
> > introduce a specific handler for new features available on recent SoCs
> > if needed. As there is not much difference on performance, the driver
> > chooses the common denominator: "User mode" which has been heavily
> > tested in [1]. "User mode" is also used as a fall back method when
> > flash device mapping window is too small.
> >
> > Problems to address with spi-mem were the configuration of the mapping
> > windows and the calibration of the read timings. The driver handles
> > them in the direct mapping handler when some knowledge on the size of
> > the flash device is know. It is not perfect but not incorrect either.
> > The algorithm is one from [1] because it doesn't require the DMA
> > registers which are not available on all controllers.
> >
> > Direct mapping for writes is not supported (yet). I have seen some
> > corruption with writes and I preferred to use the safer and proven
> > method of the initial driver [1]. We can improve that later.
> >
> > The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> > didn't have the expected results. Therefore it is not activated yet.
> > This needs more tests.
> >
> > The series does not remove the current Aspeed SMC driver but prepares
> > ground for its removal by changing its CONFIG option. This last step
> > can be addressed as a followup when the new driver using the spi-mem
> > interface has been sufficiently exposed.
> >
> > Tested on:
> >
> > * OpenPOWER Palmetto (AST2400)
> > * Evaluation board (AST2500)
> > * OpenPOWER Witherspoon (AST2500)
> > * Evaluation board (AST2600 A0)
> > * Rainier board (AST2600)
> >
> > [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> > [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
> >
> > Thanks,
> >
> > C.
> >
> > Cédric Le Goater (10):
> > mtd: spi-nor: aspeed: Rename Kconfig option
> > dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> > spi: spi-mem: Add driver for Aspeed SMC controllers
> > spi: aspeed: Add support for direct mapping
> > spi: aspeed: Adjust direct mapping to device size
> > spi: aspeed: Workaround AST2500 limitations
> > spi: aspeed: Add support for the AST2400 SPI controller
> > spi: aspeed: Calibrate read timings
> > ARM: dts: aspeed: Enable Dual SPI RX transfers
> > spi: aspeed: Activate new spi-mem driver
> >
> > drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> > .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> > arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> > arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> > arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> > drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> > drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> > drivers/spi/Kconfig | 11 +
> > drivers/spi/Makefile | 1 +
> > 9 files changed, 1369 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/spi/spi-aspeed-smc.c
> > create mode 100644
> > Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> >
> > --
> > 2.34.1
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-02 6:05 ` Tao Ren
@ 2022-03-02 6:23 ` Cédric Le Goater
2022-03-02 6:47 ` Tao Ren
2022-03-03 6:03 ` Tao Ren
0 siblings, 2 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-02 6:23 UTC (permalink / raw)
To: Tao Ren; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen, Joel Stanley
Hello Tao,
On 3/2/22 07:05, Tao Ren wrote:
> Hi Cedric,
>
> I tested v2 on wedge100 (ast2400) and cmm (ast2500). I don't see any
> functional failures except below warning on ast2400.
Thanks for the tests
> Is it something we should worry about?
>
>> spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
This means that the training failed for all HCLK settings. We never had
an AST2400 board with a second device on the FMC controller but we noticed
that any freq setting above 50MHz was unstable.
Also, aspeed-g4.dtsi does not have any "spi-max-frequency" for flash@1.
This needs an update.
> The v2 patch series (10 patches) were applied to linux stable 5.15.25,
> and below are the outputs on wedge100 (ast2400):
>
> root@wedge100-bmc:~# dmesg | grep -i spi
> [ 11.479736] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
> [ 11.704313] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> [ 11.785842] 5 fixed-partitions partitions found on MTD device spi0.0
> [ 11.862033] Creating 5 MTD partitions on "spi0.0":
> [ 13.039009] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
> [ 13.107056] spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
> [ 13.190551] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0041]
> [ 13.271959] 1 fixed-partitions partitions found on MTD device spi0.1
> [ 13.348097] Creating 1 MTD partitions on "spi0.1":
Curious. The device seems alive and very slow.
Could you please add "dyndbg="file drivers/spi/* +p;" to the bootargs
and reboot ?
> [ 28.169886] SPI driver bmp280 has no spi_device_id for bosch,bmp085
> root@wedge100-bmc:/tmp# cat /proc/mtd
> dev: size erasesize name
> mtd0: 00060000 00010000 "u-boot"
> mtd1: 00020000 00010000 "env"
> mtd2: 01b80000 00010000 "fit"
> mtd3: 00400000 00010000 "data0"
> mtd4: 02000000 00010000 "flash0"
> mtd5: 02000000 00010000 "flash1"
> root@wedge100-bmc:/tmp# ls -l flash-wedge100
> -rw-r--r-- 1 root root 22867574 Mar 1 20:49 flash-wedge100
> root@wedge100-bmc:/tmp# time flashcp flash-wedge100 /dev/mtd4
>
> real 2m22.860s
> user 0m0.478s
> sys 2m10.647s
> root@wedge100-bmc:/tmp# ls -l flash-wedge100.v2021.13.1
> -rw-r--r-- 1 root root 19743390 Mar 1 10:10 flash-wedge100.v2021.13.1
> root@wedge100-bmc:/tmp# time flashcp flash-wedge100.v2021.13.1 /dev/mtd5
>
> real 2m23.144s
> user 0m0.409s
> sys 2m10.526s
Since spi0.1 seems to be really slow, could you run
time mdsum /dev/mtd5
and compare with flash-wedge100.v2021.13.1 ? But please update
"spi-max-frequency" in the DT first.
Thanks,
C.
>
> And here are the outpus on cmm (ast2500):
>
> root@cmm001-oob:~# dmesg | grep -i spi
> [ 15.172879] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
> [ 15.361516] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> [ 15.442978] 5 fixed-partitions partitions found on MTD device spi0.0
> [ 15.519145] Creating 5 MTD partitions on "spi0.0":
> [ 15.883123] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
> [ 16.071286] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
> [ 16.152711] 1 fixed-partitions partitions found on MTD device spi0.1
> [ 16.228830] Creating 1 MTD partitions on "spi0.1":
> [ 63.831721] SPI driver bmp280 has no spi_device_id for bosch,bmp085
> root@cmm001-oob:/tmp# cat /proc/mtd
> dev: size erasesize name
> mtd0: 00060000 00001000 "u-boot"
> mtd1: 00020000 00001000 "env"
> mtd2: 01b80000 00001000 "fit"
> mtd3: 00400000 00001000 "data0"
> mtd4: 02000000 00001000 "flash0"
> mtd5: 02000000 00001000 "flash1"
> root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm
> -rw-r--r-- 1 root root 23772278 Mar 1 21:04 /tmp/flash-cmm
> root@cmm001-oob:/tmp# time flashcp /tmp/flash-cmm /dev/mtd4
> real 3m37.154s
> user 0m0.260s
> sys 3m31.700s
> root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm.v2021.48.0
> -rw-r--r-- 1 root root 23723958 Mar 1 21:07 /tmp/flash-cmm.v2021.48.0
> root@cmm001-oob:/tmp# time flashcp flash-cmm.v2021.48.0 /dev/mtd5
>
> real 3m33.843s
> user 0m0.458s
> sys 3m28.216s
>
>
> Cheers,
>
> Tao
>
> On Sun, Feb 27, 2022 at 07:53:37PM +0100, Cédric Le Goater wrote:
>> On 2/25/22 06:29, Joel Stanley wrote:
>>> Cedric has authored a new drive for the SPI NOR devices on the ASPEED
>>> SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
>>> subsystem, which should mean it can go upstream.
>>>
>>> This is great news, as our current driver is half upstream, half in
>>> the openbmc tree, due to some issues getting it merged as part of the
>>> spi-nor subsystem.
>>>
>>> It would be great to have testing. I've created a commit that patches
>>> in support to whatever kernel tree you're using. Hopefully this makes
>>> it easier to test atop your internal branches:
>>>
>>> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
>>>
>>> Cherry pick this commit into your tree, and see how it goes, and report back.
>>>
>>> I plan to switch the openbmc tree to this driver when we next rebase
>>> the kernel. We could also backport it to dev-5.15 as an option.
>>>
>>> You can direct testing results to this thread, or reply directly to
>>> the upstream thread:
>>>
>>> https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
>>
>> or grab the v2 from :
>>
>> https://github.com/legoater/linux/tree/openbmc-5.15
>>
>> I have addressed the comments on driver bind/unbind.
>>
>> Thanks,
>>
>> C.
>>
>>>
>>> Cheers,
>>>
>>> Joel
>>>
>>> ---------- Forwarded message ---------
>>> From: Cédric Le Goater <clg@kaod.org>
>>> Date: Mon, 14 Feb 2022 at 09:42
>>> Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
>>> To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
>>> Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
>>> <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
>>> Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
>>> <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
>>> <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
>>> Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
>>> <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
>>> Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
>>> <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
>>>
>>>
>>> Hi,
>>>
>>> This series adds a new SPI driver using the spi-mem interface for the
>>> Aspeed static memory controllers of the AST2600, AST2500 and AST2400
>>> SoCs.
>>>
>>> * AST2600 Firmware SPI Memory Controller (FMC)
>>> * AST2600 SPI Flash Controller (SPI1 and SPI2)
>>> * AST2500 Firmware SPI Memory Controller (FMC)
>>> * AST2500 SPI Flash Controller (SPI1 and SPI2)
>>> * AST2400 New Static Memory Controller (also referred as FMC)
>>> * AST2400 SPI Flash Controller (SPI)
>>>
>>> It is based on the current OpenBMC kernel driver [1], using directly
>>> the MTD SPI-NOR interface and on a patchset [2] previously proposed
>>> adding support for the AST2600 only. This driver takes a slightly
>>> different approach to cover all 6 controllers.
>>>
>>> It does not make use of the controller register disabling Address and
>>> Data byte lanes because is not available on the AST2400 SoC. We could
>>> introduce a specific handler for new features available on recent SoCs
>>> if needed. As there is not much difference on performance, the driver
>>> chooses the common denominator: "User mode" which has been heavily
>>> tested in [1]. "User mode" is also used as a fall back method when
>>> flash device mapping window is too small.
>>>
>>> Problems to address with spi-mem were the configuration of the mapping
>>> windows and the calibration of the read timings. The driver handles
>>> them in the direct mapping handler when some knowledge on the size of
>>> the flash device is know. It is not perfect but not incorrect either.
>>> The algorithm is one from [1] because it doesn't require the DMA
>>> registers which are not available on all controllers.
>>>
>>> Direct mapping for writes is not supported (yet). I have seen some
>>> corruption with writes and I preferred to use the safer and proven
>>> method of the initial driver [1]. We can improve that later.
>>>
>>> The driver supports Quad SPI RX transfers on the AST2600 SoC but it
>>> didn't have the expected results. Therefore it is not activated yet.
>>> This needs more tests.
>>>
>>> The series does not remove the current Aspeed SMC driver but prepares
>>> ground for its removal by changing its CONFIG option. This last step
>>> can be addressed as a followup when the new driver using the spi-mem
>>> interface has been sufficiently exposed.
>>>
>>> Tested on:
>>>
>>> * OpenPOWER Palmetto (AST2400)
>>> * Evaluation board (AST2500)
>>> * OpenPOWER Witherspoon (AST2500)
>>> * Evaluation board (AST2600 A0)
>>> * Rainier board (AST2600)
>>>
>>> [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
>>> [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
>>>
>>> Thanks,
>>>
>>> C.
>>>
>>> Cédric Le Goater (10):
>>> mtd: spi-nor: aspeed: Rename Kconfig option
>>> dt-bindings: spi: Add Aspeed SMC controllers device tree binding
>>> spi: spi-mem: Add driver for Aspeed SMC controllers
>>> spi: aspeed: Add support for direct mapping
>>> spi: aspeed: Adjust direct mapping to device size
>>> spi: aspeed: Workaround AST2500 limitations
>>> spi: aspeed: Add support for the AST2400 SPI controller
>>> spi: aspeed: Calibrate read timings
>>> ARM: dts: aspeed: Enable Dual SPI RX transfers
>>> spi: aspeed: Activate new spi-mem driver
>>>
>>> drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
>>> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
>>> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
>>> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
>>> arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
>>> drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
>>> drivers/mtd/spi-nor/controllers/Makefile | 2 +-
>>> drivers/spi/Kconfig | 11 +
>>> drivers/spi/Makefile | 1 +
>>> 9 files changed, 1369 insertions(+), 3 deletions(-)
>>> create mode 100644 drivers/spi/spi-aspeed-smc.c
>>> create mode 100644
>>> Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>>>
>>> --
>>> 2.34.1
>>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-02 6:23 ` Cédric Le Goater
@ 2022-03-02 6:47 ` Tao Ren
2022-03-03 6:03 ` Tao Ren
1 sibling, 0 replies; 115+ messages in thread
From: Tao Ren @ 2022-03-02 6:47 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen, Joel Stanley
Hi Cedric,
Sure. Let me make the changes and will share you the results tomorrow.
Cheers,
Tao
On Wed, Mar 02, 2022 at 07:23:15AM +0100, Cédric Le Goater wrote:
> Hello Tao,
>
> On 3/2/22 07:05, Tao Ren wrote:
> > Hi Cedric,
> >
> > I tested v2 on wedge100 (ast2400) and cmm (ast2500). I don't see any
> > functional failures except below warning on ast2400.
>
> Thanks for the tests
>
> > Is it something we should worry about?
> >
> > > spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
>
>
> This means that the training failed for all HCLK settings. We never had
> an AST2400 board with a second device on the FMC controller but we noticed
> that any freq setting above 50MHz was unstable.
>
> Also, aspeed-g4.dtsi does not have any "spi-max-frequency" for flash@1.
> This needs an update.
>
> > The v2 patch series (10 patches) were applied to linux stable 5.15.25,
> > and below are the outputs on wedge100 (ast2400):
> >
> > root@wedge100-bmc:~# dmesg | grep -i spi
> > [ 11.479736] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
> > [ 11.704313] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> > [ 11.785842] 5 fixed-partitions partitions found on MTD device spi0.0
> > [ 11.862033] Creating 5 MTD partitions on "spi0.0":
> > [ 13.039009] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
> > [ 13.107056] spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
> > [ 13.190551] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0041]
> > [ 13.271959] 1 fixed-partitions partitions found on MTD device spi0.1
> > [ 13.348097] Creating 1 MTD partitions on "spi0.1":
>
> Curious. The device seems alive and very slow.
>
> Could you please add "dyndbg="file drivers/spi/* +p;" to the bootargs
> and reboot ?
>
>
> > [ 28.169886] SPI driver bmp280 has no spi_device_id for bosch,bmp085
> > root@wedge100-bmc:/tmp# cat /proc/mtd
> > dev: size erasesize name
> > mtd0: 00060000 00010000 "u-boot"
> > mtd1: 00020000 00010000 "env"
> > mtd2: 01b80000 00010000 "fit"
> > mtd3: 00400000 00010000 "data0"
> > mtd4: 02000000 00010000 "flash0"
> > mtd5: 02000000 00010000 "flash1"
> > root@wedge100-bmc:/tmp# ls -l flash-wedge100
> > -rw-r--r-- 1 root root 22867574 Mar 1 20:49 flash-wedge100
> > root@wedge100-bmc:/tmp# time flashcp flash-wedge100 /dev/mtd4
> >
> > real 2m22.860s
> > user 0m0.478s
> > sys 2m10.647s
> > root@wedge100-bmc:/tmp# ls -l flash-wedge100.v2021.13.1
> > -rw-r--r-- 1 root root 19743390 Mar 1 10:10 flash-wedge100.v2021.13.1
> > root@wedge100-bmc:/tmp# time flashcp flash-wedge100.v2021.13.1 /dev/mtd5
> >
> > real 2m23.144s
> > user 0m0.409s
> > sys 2m10.526s
>
> Since spi0.1 seems to be really slow, could you run
>
> time mdsum /dev/mtd5
>
> and compare with flash-wedge100.v2021.13.1 ? But please update
> "spi-max-frequency" in the DT first.
>
> Thanks,
>
> C.
>
> >
> > And here are the outpus on cmm (ast2500):
> >
> > root@cmm001-oob:~# dmesg | grep -i spi
> > [ 15.172879] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
> > [ 15.361516] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> > [ 15.442978] 5 fixed-partitions partitions found on MTD device spi0.0
> > [ 15.519145] Creating 5 MTD partitions on "spi0.0":
> > [ 15.883123] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
> > [ 16.071286] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
> > [ 16.152711] 1 fixed-partitions partitions found on MTD device spi0.1
> > [ 16.228830] Creating 1 MTD partitions on "spi0.1":
> > [ 63.831721] SPI driver bmp280 has no spi_device_id for bosch,bmp085
> > root@cmm001-oob:/tmp# cat /proc/mtd
> > dev: size erasesize name
> > mtd0: 00060000 00001000 "u-boot"
> > mtd1: 00020000 00001000 "env"
> > mtd2: 01b80000 00001000 "fit"
> > mtd3: 00400000 00001000 "data0"
> > mtd4: 02000000 00001000 "flash0"
> > mtd5: 02000000 00001000 "flash1"
> > root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm
> > -rw-r--r-- 1 root root 23772278 Mar 1 21:04 /tmp/flash-cmm
> > root@cmm001-oob:/tmp# time flashcp /tmp/flash-cmm /dev/mtd4
> > real 3m37.154s
> > user 0m0.260s
> > sys 3m31.700s
> > root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm.v2021.48.0
> > -rw-r--r-- 1 root root 23723958 Mar 1 21:07 /tmp/flash-cmm.v2021.48.0
> > root@cmm001-oob:/tmp# time flashcp flash-cmm.v2021.48.0 /dev/mtd5
> >
> > real 3m33.843s
> > user 0m0.458s
> > sys 3m28.216s
> >
> >
> > Cheers,
> >
> > Tao
> >
> > On Sun, Feb 27, 2022 at 07:53:37PM +0100, Cédric Le Goater wrote:
> > > On 2/25/22 06:29, Joel Stanley wrote:
> > > > Cedric has authored a new drive for the SPI NOR devices on the ASPEED
> > > > SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
> > > > subsystem, which should mean it can go upstream.
> > > >
> > > > This is great news, as our current driver is half upstream, half in
> > > > the openbmc tree, due to some issues getting it merged as part of the
> > > > spi-nor subsystem.
> > > >
> > > > It would be great to have testing. I've created a commit that patches
> > > > in support to whatever kernel tree you're using. Hopefully this makes
> > > > it easier to test atop your internal branches:
> > > >
> > > > https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
> > > >
> > > > Cherry pick this commit into your tree, and see how it goes, and report back.
> > > >
> > > > I plan to switch the openbmc tree to this driver when we next rebase
> > > > the kernel. We could also backport it to dev-5.15 as an option.
> > > >
> > > > You can direct testing results to this thread, or reply directly to
> > > > the upstream thread:
> > > >
> > > > https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
> > >
> > > or grab the v2 from :
> > >
> > > https://github.com/legoater/linux/tree/openbmc-5.15
> > >
> > > I have addressed the comments on driver bind/unbind.
> > >
> > > Thanks,
> > >
> > > C.
> > >
> > > >
> > > > Cheers,
> > > >
> > > > Joel
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: Cédric Le Goater <clg@kaod.org>
> > > > Date: Mon, 14 Feb 2022 at 09:42
> > > > Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
> > > > To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
> > > > Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
> > > > <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
> > > > Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
> > > > <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
> > > > <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
> > > > Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
> > > > <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
> > > > Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
> > > > <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
> > > >
> > > >
> > > > Hi,
> > > >
> > > > This series adds a new SPI driver using the spi-mem interface for the
> > > > Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> > > > SoCs.
> > > >
> > > > * AST2600 Firmware SPI Memory Controller (FMC)
> > > > * AST2600 SPI Flash Controller (SPI1 and SPI2)
> > > > * AST2500 Firmware SPI Memory Controller (FMC)
> > > > * AST2500 SPI Flash Controller (SPI1 and SPI2)
> > > > * AST2400 New Static Memory Controller (also referred as FMC)
> > > > * AST2400 SPI Flash Controller (SPI)
> > > >
> > > > It is based on the current OpenBMC kernel driver [1], using directly
> > > > the MTD SPI-NOR interface and on a patchset [2] previously proposed
> > > > adding support for the AST2600 only. This driver takes a slightly
> > > > different approach to cover all 6 controllers.
> > > >
> > > > It does not make use of the controller register disabling Address and
> > > > Data byte lanes because is not available on the AST2400 SoC. We could
> > > > introduce a specific handler for new features available on recent SoCs
> > > > if needed. As there is not much difference on performance, the driver
> > > > chooses the common denominator: "User mode" which has been heavily
> > > > tested in [1]. "User mode" is also used as a fall back method when
> > > > flash device mapping window is too small.
> > > >
> > > > Problems to address with spi-mem were the configuration of the mapping
> > > > windows and the calibration of the read timings. The driver handles
> > > > them in the direct mapping handler when some knowledge on the size of
> > > > the flash device is know. It is not perfect but not incorrect either.
> > > > The algorithm is one from [1] because it doesn't require the DMA
> > > > registers which are not available on all controllers.
> > > >
> > > > Direct mapping for writes is not supported (yet). I have seen some
> > > > corruption with writes and I preferred to use the safer and proven
> > > > method of the initial driver [1]. We can improve that later.
> > > >
> > > > The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> > > > didn't have the expected results. Therefore it is not activated yet.
> > > > This needs more tests.
> > > >
> > > > The series does not remove the current Aspeed SMC driver but prepares
> > > > ground for its removal by changing its CONFIG option. This last step
> > > > can be addressed as a followup when the new driver using the spi-mem
> > > > interface has been sufficiently exposed.
> > > >
> > > > Tested on:
> > > >
> > > > * OpenPOWER Palmetto (AST2400)
> > > > * Evaluation board (AST2500)
> > > > * OpenPOWER Witherspoon (AST2500)
> > > > * Evaluation board (AST2600 A0)
> > > > * Rainier board (AST2600)
> > > >
> > > > [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> > > > [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
> > > >
> > > > Thanks,
> > > >
> > > > C.
> > > >
> > > > Cédric Le Goater (10):
> > > > mtd: spi-nor: aspeed: Rename Kconfig option
> > > > dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> > > > spi: spi-mem: Add driver for Aspeed SMC controllers
> > > > spi: aspeed: Add support for direct mapping
> > > > spi: aspeed: Adjust direct mapping to device size
> > > > spi: aspeed: Workaround AST2500 limitations
> > > > spi: aspeed: Add support for the AST2400 SPI controller
> > > > spi: aspeed: Calibrate read timings
> > > > ARM: dts: aspeed: Enable Dual SPI RX transfers
> > > > spi: aspeed: Activate new spi-mem driver
> > > >
> > > > drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> > > > .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> > > > arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> > > > arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> > > > arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> > > > drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> > > > drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> > > > drivers/spi/Kconfig | 11 +
> > > > drivers/spi/Makefile | 1 +
> > > > 9 files changed, 1369 insertions(+), 3 deletions(-)
> > > > create mode 100644 drivers/spi/spi-aspeed-smc.c
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> > > >
> > > > --
> > > > 2.34.1
> > >
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-02 6:23 ` Cédric Le Goater
2022-03-02 6:47 ` Tao Ren
@ 2022-03-03 6:03 ` Tao Ren
2022-03-03 7:02 ` Cédric Le Goater
1 sibling, 1 reply; 115+ messages in thread
From: Tao Ren @ 2022-03-03 6:03 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen, Joel Stanley
Hi Cedric,
The "No good frequency" warning is gone after updating spi-max-frequency
to 50MHz in aspeed-g4.dtsi (thanks). I don't see any functional failures,
but flashcp ran slower compared to the mtd/spi-nor driver(~200 sec vs.
~145 sec when flashcp 32MB data to flash1).
Below are the new results on ast2400:
root@wedge100-bmc:~# dmesg | grep -i spi
[ 11.501808] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
[ 11.726388] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
[ 11.807925] 5 fixed-partitions partitions found on MTD device spi0.0
[ 11.884113] Creating 5 MTD partitions on "spi0.0":
[ 13.036819] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
[ 13.260858] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
[ 13.342318] 1 fixed-partitions partitions found on MTD device spi0.1
[ 13.418426] Creating 1 MTD partitions on "spi0.1":
[ 28.239488] SPI driver bmp280 has no spi_device_id for bosch,bmp085
root@wedge100-bmc:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00060000 00010000 "u-boot"
mtd1: 00020000 00010000 "env"
mtd2: 01b80000 00010000 "fit"
mtd3: 00400000 00010000 "data0"
mtd4: 02000000 00010000 "flash0"
mtd5: 02000000 00010000 "flash1"
root@wedge100-bmc:~# dd if=/dev/urandom of=/tmp/dummy.bin bs=32MB count=1
1+0 records in
1+0 records out
root@wedge100-bmc:~# ls -l /tmp/dummy.bin
-rw-r--r-- 1 root root 32000000 Mar 2 14:45 /tmp/dummy.bin
root@wedge100-bmc:~# time flashcp /tmp/dummy.bin /dev/mtd5
real 3m21.837s
user 0m0.557s
sys 3m4.629s
root@wedge100-bmc:~# time md5sum /dev/mtd5
6903a022e1e8f624ed3beb31aa94c528 /dev/mtd5
real 0m6.869s
user 0m2.492s
sys 0m3.738s
root@wedge100-bmc:~# md5sum /tmp/dummy.bin
7205977a323b482f637123e43ab31a18 /tmp/dummy.bin
And below are the logs after appending "dyndbg" boot args:
root@wedge100-bmc:~# dmesg | grep -i spi
[ 0.000000] Kernel command line: console=ttyS2,9600n8 root=/dev/ram rw dyndbg="file drivers/spi/* +p;"
[ 11.594461] spi-aspeed-smc 1e620000.spi: registered master spi0
[ 11.594628] spi-aspeed-smc 1e620000.spi: CE0 default window [ 0x20000000 - 0x21ffffff ] 32MB
[ 11.594709] spi-aspeed-smc 1e620000.spi: CE0 setup done
[ 11.594763] spi spi0.0: setup mode 0, 8 bits/w, 50000000 Hz max --> 0
[ 11.595737] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x9f mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x6
[ 11.595950] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x10
[ 11.596103] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x8
[ 11.596226] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x70
[ 11.596513] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x24
[ 11.596732] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
[ 11.658369] spi-aspeed-smc 1e620000.spi: CE1 new window [ 0x22000000 - 0x23ffffff ] 32MB
[ 11.658457] spi-aspeed-smc 1e620000.spi: calculate timing compensation - AHB freq: 180 MHz
[ 11.664951] spi-aspeed-smc 1e620000.spi: Trying HCLK/5 [203c0d41] ...
[ 11.692905] spi-aspeed-smc 1e620000.spi: * [00080000] 0 HCLK delay, 4ns DI delay : PASS
[ 11.720911] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 0ns DI delay : PASS
[ 11.749067] spi-aspeed-smc 1e620000.spi: * [00090000] 1 HCLK delay, 4ns DI delay : PASS
[ 11.749155] spi-aspeed-smc 1e620000.spi: * -> good is pass 1 [0x00000000]
[ 11.749209] spi-aspeed-smc 1e620000.spi: Trying HCLK/4 [203c0641] ...
[ 11.773556] spi-aspeed-smc 1e620000.spi: * [00008000] 0 HCLK delay, 4ns DI delay : PASS
[ 11.797835] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 0ns DI delay : PASS
[ 11.822419] spi-aspeed-smc 1e620000.spi: * [00009000] 1 HCLK delay, 4ns DI delay : PASS
[ 11.822505] spi-aspeed-smc 1e620000.spi: * -> good is pass 1 [0x00000000]
[ 11.822558] spi-aspeed-smc 1e620000.spi: Found good read timings at HCLK/4
[ 11.822607] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
[ 11.904076] 5 fixed-partitions partitions found on MTD device spi0.0
[ 11.980270] Creating 5 MTD partitions on "spi0.0":
[ 13.151908] spi-aspeed-smc 1e620000.spi: registered child spi0.0
[ 13.152074] spi-aspeed-smc 1e620000.spi: CE1 default window [ 0x22000000 - 0x23ffffff ] 32MB
[ 13.152151] spi-aspeed-smc 1e620000.spi: CE1 setup done
[ 13.152201] spi spi0.1: setup mode 0, 8 bits/w, 50000000 Hz max --> 0
[ 13.153185] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x9f mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x6
[ 13.153399] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x10
[ 13.153552] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x8
[ 13.153674] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x70
[ 13.153961] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x24
[ 13.154180] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
[ 13.215872] spi-aspeed-smc 1e620000.spi: CE2 new window [ 0x24000000 - 0x25ffffff ] 32MB
[ 13.215962] spi-aspeed-smc 1e620000.spi: calculate timing compensation - AHB freq: 180 MHz
[ 13.222431] spi-aspeed-smc 1e620000.spi: Trying HCLK/5 [203c0d41] ...
[ 13.250258] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 4ns DI delay : PASS
[ 13.278256] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 0ns DI delay : PASS
[ 13.306252] spi-aspeed-smc 1e620000.spi: * [00000000] 1 HCLK delay, 4ns DI delay : PASS
[ 13.306337] spi-aspeed-smc 1e620000.spi: * -> good is pass 1 [0x00000000]
[ 13.306392] spi-aspeed-smc 1e620000.spi: Trying HCLK/4 [203c0641] ...
[ 13.330735] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 4ns DI delay : PASS
[ 13.355007] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 0ns DI delay : PASS
[ 13.379274] spi-aspeed-smc 1e620000.spi: * [00000000] 1 HCLK delay, 4ns DI delay : PASS
[ 13.379362] spi-aspeed-smc 1e620000.spi: * -> good is pass 1 [0x00000000]
[ 13.379416] spi-aspeed-smc 1e620000.spi: Found good read timings at HCLK/4
[ 13.379465] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
[ 13.460934] 1 fixed-partitions partitions found on MTD device spi0.1
[ 13.537042] Creating 1 MTD partitions on "spi0.1":
[ 14.145255] spi-aspeed-smc 1e620000.spi: registered child spi0.1
[ 28.287508] SPI driver bmp280 has no spi_device_id for bosch,bmp085
[ 116.047752] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
[ 116.047894] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0x44
[ 116.048011] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
[ 116.048109] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
[ 116.048260] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
[ 116.048363] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0xc
[ 116.048461] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
[ 116.049421] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
[ 116.049559] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0x44
[ 116.049676] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
[ 116.049773] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
[ 116.049872] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
[ 116.049969] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0x39
[ 116.050070] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
[ 116.050159] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
[ 116.050307] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
[ 116.050416] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0xc
[ 116.050513] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
Cheers,
Tao
On Wed, Mar 02, 2022 at 07:23:15AM +0100, Cédric Le Goater wrote:
> Hello Tao,
>
> On 3/2/22 07:05, Tao Ren wrote:
> > Hi Cedric,
> >
> > I tested v2 on wedge100 (ast2400) and cmm (ast2500). I don't see any
> > functional failures except below warning on ast2400.
>
> Thanks for the tests
>
> > Is it something we should worry about?
> >
> > > spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
>
>
> This means that the training failed for all HCLK settings. We never had
> an AST2400 board with a second device on the FMC controller but we noticed
> that any freq setting above 50MHz was unstable.
>
> Also, aspeed-g4.dtsi does not have any "spi-max-frequency" for flash@1.
> This needs an update.
>
> > The v2 patch series (10 patches) were applied to linux stable 5.15.25,
> > and below are the outputs on wedge100 (ast2400):
> >
> > root@wedge100-bmc:~# dmesg | grep -i spi
> > [ 11.479736] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
> > [ 11.704313] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> > [ 11.785842] 5 fixed-partitions partitions found on MTD device spi0.0
> > [ 11.862033] Creating 5 MTD partitions on "spi0.0":
> > [ 13.039009] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
> > [ 13.107056] spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
> > [ 13.190551] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0041]
> > [ 13.271959] 1 fixed-partitions partitions found on MTD device spi0.1
> > [ 13.348097] Creating 1 MTD partitions on "spi0.1":
>
> Curious. The device seems alive and very slow.
>
> Could you please add "dyndbg="file drivers/spi/* +p;" to the bootargs
> and reboot ?
>
>
> > [ 28.169886] SPI driver bmp280 has no spi_device_id for bosch,bmp085
> > root@wedge100-bmc:/tmp# cat /proc/mtd
> > dev: size erasesize name
> > mtd0: 00060000 00010000 "u-boot"
> > mtd1: 00020000 00010000 "env"
> > mtd2: 01b80000 00010000 "fit"
> > mtd3: 00400000 00010000 "data0"
> > mtd4: 02000000 00010000 "flash0"
> > mtd5: 02000000 00010000 "flash1"
> > root@wedge100-bmc:/tmp# ls -l flash-wedge100
> > -rw-r--r-- 1 root root 22867574 Mar 1 20:49 flash-wedge100
> > root@wedge100-bmc:/tmp# time flashcp flash-wedge100 /dev/mtd4
> >
> > real 2m22.860s
> > user 0m0.478s
> > sys 2m10.647s
> > root@wedge100-bmc:/tmp# ls -l flash-wedge100.v2021.13.1
> > -rw-r--r-- 1 root root 19743390 Mar 1 10:10 flash-wedge100.v2021.13.1
> > root@wedge100-bmc:/tmp# time flashcp flash-wedge100.v2021.13.1 /dev/mtd5
> >
> > real 2m23.144s
> > user 0m0.409s
> > sys 2m10.526s
>
> Since spi0.1 seems to be really slow, could you run
>
> time mdsum /dev/mtd5
>
> and compare with flash-wedge100.v2021.13.1 ? But please update
> "spi-max-frequency" in the DT first.
>
> Thanks,
>
> C.
>
> >
> > And here are the outpus on cmm (ast2500):
> >
> > root@cmm001-oob:~# dmesg | grep -i spi
> > [ 15.172879] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
> > [ 15.361516] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> > [ 15.442978] 5 fixed-partitions partitions found on MTD device spi0.0
> > [ 15.519145] Creating 5 MTD partitions on "spi0.0":
> > [ 15.883123] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
> > [ 16.071286] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
> > [ 16.152711] 1 fixed-partitions partitions found on MTD device spi0.1
> > [ 16.228830] Creating 1 MTD partitions on "spi0.1":
> > [ 63.831721] SPI driver bmp280 has no spi_device_id for bosch,bmp085
> > root@cmm001-oob:/tmp# cat /proc/mtd
> > dev: size erasesize name
> > mtd0: 00060000 00001000 "u-boot"
> > mtd1: 00020000 00001000 "env"
> > mtd2: 01b80000 00001000 "fit"
> > mtd3: 00400000 00001000 "data0"
> > mtd4: 02000000 00001000 "flash0"
> > mtd5: 02000000 00001000 "flash1"
> > root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm
> > -rw-r--r-- 1 root root 23772278 Mar 1 21:04 /tmp/flash-cmm
> > root@cmm001-oob:/tmp# time flashcp /tmp/flash-cmm /dev/mtd4
> > real 3m37.154s
> > user 0m0.260s
> > sys 3m31.700s
> > root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm.v2021.48.0
> > -rw-r--r-- 1 root root 23723958 Mar 1 21:07 /tmp/flash-cmm.v2021.48.0
> > root@cmm001-oob:/tmp# time flashcp flash-cmm.v2021.48.0 /dev/mtd5
> >
> > real 3m33.843s
> > user 0m0.458s
> > sys 3m28.216s
> >
> >
> > Cheers,
> >
> > Tao
> >
> > On Sun, Feb 27, 2022 at 07:53:37PM +0100, Cédric Le Goater wrote:
> > > On 2/25/22 06:29, Joel Stanley wrote:
> > > > Cedric has authored a new drive for the SPI NOR devices on the ASPEED
> > > > SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
> > > > subsystem, which should mean it can go upstream.
> > > >
> > > > This is great news, as our current driver is half upstream, half in
> > > > the openbmc tree, due to some issues getting it merged as part of the
> > > > spi-nor subsystem.
> > > >
> > > > It would be great to have testing. I've created a commit that patches
> > > > in support to whatever kernel tree you're using. Hopefully this makes
> > > > it easier to test atop your internal branches:
> > > >
> > > > https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
> > > >
> > > > Cherry pick this commit into your tree, and see how it goes, and report back.
> > > >
> > > > I plan to switch the openbmc tree to this driver when we next rebase
> > > > the kernel. We could also backport it to dev-5.15 as an option.
> > > >
> > > > You can direct testing results to this thread, or reply directly to
> > > > the upstream thread:
> > > >
> > > > https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
> > >
> > > or grab the v2 from :
> > >
> > > https://github.com/legoater/linux/tree/openbmc-5.15
> > >
> > > I have addressed the comments on driver bind/unbind.
> > >
> > > Thanks,
> > >
> > > C.
> > >
> > > >
> > > > Cheers,
> > > >
> > > > Joel
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: Cédric Le Goater <clg@kaod.org>
> > > > Date: Mon, 14 Feb 2022 at 09:42
> > > > Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
> > > > To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
> > > > Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
> > > > <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
> > > > Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
> > > > <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
> > > > <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
> > > > Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
> > > > <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
> > > > Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
> > > > <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
> > > >
> > > >
> > > > Hi,
> > > >
> > > > This series adds a new SPI driver using the spi-mem interface for the
> > > > Aspeed static memory controllers of the AST2600, AST2500 and AST2400
> > > > SoCs.
> > > >
> > > > * AST2600 Firmware SPI Memory Controller (FMC)
> > > > * AST2600 SPI Flash Controller (SPI1 and SPI2)
> > > > * AST2500 Firmware SPI Memory Controller (FMC)
> > > > * AST2500 SPI Flash Controller (SPI1 and SPI2)
> > > > * AST2400 New Static Memory Controller (also referred as FMC)
> > > > * AST2400 SPI Flash Controller (SPI)
> > > >
> > > > It is based on the current OpenBMC kernel driver [1], using directly
> > > > the MTD SPI-NOR interface and on a patchset [2] previously proposed
> > > > adding support for the AST2600 only. This driver takes a slightly
> > > > different approach to cover all 6 controllers.
> > > >
> > > > It does not make use of the controller register disabling Address and
> > > > Data byte lanes because is not available on the AST2400 SoC. We could
> > > > introduce a specific handler for new features available on recent SoCs
> > > > if needed. As there is not much difference on performance, the driver
> > > > chooses the common denominator: "User mode" which has been heavily
> > > > tested in [1]. "User mode" is also used as a fall back method when
> > > > flash device mapping window is too small.
> > > >
> > > > Problems to address with spi-mem were the configuration of the mapping
> > > > windows and the calibration of the read timings. The driver handles
> > > > them in the direct mapping handler when some knowledge on the size of
> > > > the flash device is know. It is not perfect but not incorrect either.
> > > > The algorithm is one from [1] because it doesn't require the DMA
> > > > registers which are not available on all controllers.
> > > >
> > > > Direct mapping for writes is not supported (yet). I have seen some
> > > > corruption with writes and I preferred to use the safer and proven
> > > > method of the initial driver [1]. We can improve that later.
> > > >
> > > > The driver supports Quad SPI RX transfers on the AST2600 SoC but it
> > > > didn't have the expected results. Therefore it is not activated yet.
> > > > This needs more tests.
> > > >
> > > > The series does not remove the current Aspeed SMC driver but prepares
> > > > ground for its removal by changing its CONFIG option. This last step
> > > > can be addressed as a followup when the new driver using the spi-mem
> > > > interface has been sufficiently exposed.
> > > >
> > > > Tested on:
> > > >
> > > > * OpenPOWER Palmetto (AST2400)
> > > > * Evaluation board (AST2500)
> > > > * OpenPOWER Witherspoon (AST2500)
> > > > * Evaluation board (AST2600 A0)
> > > > * Rainier board (AST2600)
> > > >
> > > > [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> > > > [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
> > > >
> > > > Thanks,
> > > >
> > > > C.
> > > >
> > > > Cédric Le Goater (10):
> > > > mtd: spi-nor: aspeed: Rename Kconfig option
> > > > dt-bindings: spi: Add Aspeed SMC controllers device tree binding
> > > > spi: spi-mem: Add driver for Aspeed SMC controllers
> > > > spi: aspeed: Add support for direct mapping
> > > > spi: aspeed: Adjust direct mapping to device size
> > > > spi: aspeed: Workaround AST2500 limitations
> > > > spi: aspeed: Add support for the AST2400 SPI controller
> > > > spi: aspeed: Calibrate read timings
> > > > ARM: dts: aspeed: Enable Dual SPI RX transfers
> > > > spi: aspeed: Activate new spi-mem driver
> > > >
> > > > drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
> > > > .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
> > > > arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> > > > arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
> > > > arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
> > > > drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
> > > > drivers/mtd/spi-nor/controllers/Makefile | 2 +-
> > > > drivers/spi/Kconfig | 11 +
> > > > drivers/spi/Makefile | 1 +
> > > > 9 files changed, 1369 insertions(+), 3 deletions(-)
> > > > create mode 100644 drivers/spi/spi-aspeed-smc.c
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
> > > >
> > > > --
> > > > 2.34.1
> > >
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-03 6:03 ` Tao Ren
@ 2022-03-03 7:02 ` Cédric Le Goater
2022-03-04 7:53 ` Tao Ren
0 siblings, 1 reply; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-03 7:02 UTC (permalink / raw)
To: Tao Ren; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen, Joel Stanley
Hello Tao,
On 3/3/22 07:03, Tao Ren wrote:
> Hi Cedric,
>
> The "No good frequency" warning is gone after updating spi-max-frequency
> to 50MHz in aspeed-g4.dtsi (thanks). I don't see any functional failures,
Super !
May be send the "spi-max-frequency" patch ? I can include it in a v3 if a
resend is needed.
> but flashcp ran slower compared to the mtd/spi-nor driver(~200 sec vs.
> ~145 sec when flashcp 32MB data to flash1).
Interesting, the HW settings should be the same. Was the dynamic debug
activated ?
> Below are the new results on ast2400:
>
> root@wedge100-bmc:~# dmesg | grep -i spi
> [ 11.501808] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
> [ 11.726388] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> [ 11.807925] 5 fixed-partitions partitions found on MTD device spi0.0
> [ 11.884113] Creating 5 MTD partitions on "spi0.0":
> [ 13.036819] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
> [ 13.260858] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
> [ 13.342318] 1 fixed-partitions partitions found on MTD device spi0.1
> [ 13.418426] Creating 1 MTD partitions on "spi0.1":
> [ 28.239488] SPI driver bmp280 has no spi_device_id for bosch,bmp085
> root@wedge100-bmc:~# cat /proc/mtd
> dev: size erasesize name
> mtd0: 00060000 00010000 "u-boot"
> mtd1: 00020000 00010000 "env"
> mtd2: 01b80000 00010000 "fit"
> mtd3: 00400000 00010000 "data0"
> mtd4: 02000000 00010000 "flash0"
> mtd5: 02000000 00010000 "flash1"
> root@wedge100-bmc:~# dd if=/dev/urandom of=/tmp/dummy.bin bs=32MB count=1
> 1+0 records in
> 1+0 records out
> root@wedge100-bmc:~# ls -l /tmp/dummy.bin
> -rw-r--r-- 1 root root 32000000 Mar 2 14:45 /tmp/dummy.bin
> root@wedge100-bmc:~# time flashcp /tmp/dummy.bin /dev/mtd5
>
> real 3m21.837s
> user 0m0.557s
> sys 3m4.629s
> root@wedge100-bmc:~# time md5sum /dev/mtd5
> 6903a022e1e8f624ed3beb31aa94c528 /dev/mtd5
>
> real 0m6.869s
> user 0m2.492s
> sys 0m3.738s
> root@wedge100-bmc:~# md5sum /tmp/dummy.bin
> 7205977a323b482f637123e43ab31a18 /tmp/dummy.bin
>
> And below are the logs after appending "dyndbg" boot args:
>
> root@wedge100-bmc:~# dmesg | grep -i spi
> [ 0.000000] Kernel command line: console=ttyS2,9600n8 root=/dev/ram rw dyndbg="file drivers/spi/* +p;"
> [ 11.594461] spi-aspeed-smc 1e620000.spi: registered master spi0
> [ 11.594628] spi-aspeed-smc 1e620000.spi: CE0 default window [ 0x20000000 - 0x21ffffff ] 32MB
> [ 11.594709] spi-aspeed-smc 1e620000.spi: CE0 setup done
> [ 11.594763] spi spi0.0: setup mode 0, 8 bits/w, 50000000 Hz max --> 0
> [ 11.595737] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x9f mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x6
> [ 11.595950] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x10
> [ 11.596103] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x8
> [ 11.596226] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x70
> [ 11.596513] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x24
> [ 11.596732] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
I am quite sure this is a MX25L25635F. I add this little patch to my kernel
to check :
@@ -22,8 +22,10 @@ mx25l25635_post_bfpt_fixups(struct spi_n
* seems that the F version advertises support for Fast Read 4-4-4 in
* its BFPT table.
*/
- if (bfpt->dwords[BFPT_DWORD(5)] & BFPT_DWORD5_FAST_READ_4_4_4)
+ if (bfpt->dwords[BFPT_DWORD(5)] & BFPT_DWORD5_FAST_READ_4_4_4) {
+ dev_warn(nor->dev, "This is a MX25L25635F\n");
nor->flags |= SNOR_F_4B_OPCODES;
+ }
return 0;
}
It would be nice to change the spi-nor layer to report the name correctly
one day. I will see what can be done.
> [ 11.658369] spi-aspeed-smc 1e620000.spi: CE1 new window [ 0x22000000 - 0x23ffffff ] 32MB
> [ 11.658457] spi-aspeed-smc 1e620000.spi: calculate timing compensation - AHB freq: 180 MHz
> [ 11.664951] spi-aspeed-smc 1e620000.spi: Trying HCLK/5 [203c0d41] ...
> [ 11.692905] spi-aspeed-smc 1e620000.spi: * [00080000] 0 HCLK delay, 4ns DI delay : PASS
> [ 11.720911] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 0ns DI delay : PASS
> [ 11.749067] spi-aspeed-smc 1e620000.spi: * [00090000] 1 HCLK delay, 4ns DI delay : PASS
> [ 11.749155] spi-aspeed-smc 1e620000.spi: * -> good is pass 1 [0x00000000]
> [ 11.749209] spi-aspeed-smc 1e620000.spi: Trying HCLK/4 [203c0641] ...
> [ 11.773556] spi-aspeed-smc 1e620000.spi: * [00008000] 0 HCLK delay, 4ns DI delay : PASS
> [ 11.797835] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 0ns DI delay : PASS
> [ 11.822419] spi-aspeed-smc 1e620000.spi: * [00009000] 1 HCLK delay, 4ns DI delay : PASS
> [ 11.822505] spi-aspeed-smc 1e620000.spi: * -> good is pass 1 [0x00000000]
> [ 11.822558] spi-aspeed-smc 1e620000.spi: Found good read timings at HCLK/4
> [ 11.822607] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> [ 11.904076] 5 fixed-partitions partitions found on MTD device spi0.0
> [ 11.980270] Creating 5 MTD partitions on "spi0.0":
> [ 13.151908] spi-aspeed-smc 1e620000.spi: registered child spi0.0
> [ 13.152074] spi-aspeed-smc 1e620000.spi: CE1 default window [ 0x22000000 - 0x23ffffff ] 32MB
> [ 13.152151] spi-aspeed-smc 1e620000.spi: CE1 setup done
> [ 13.152201] spi spi0.1: setup mode 0, 8 bits/w, 50000000 Hz max --> 0
> [ 13.153185] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x9f mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x6
> [ 13.153399] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x10
> [ 13.153552] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x8
> [ 13.153674] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x70
> [ 13.153961] spi-aspeed-smc 1e620000.spi: CE1 read OP 0x5a mode:1.1.1.1 naddr:0x3 ndummies:0x1 len:0x24
> [ 13.154180] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
> [ 13.215872] spi-aspeed-smc 1e620000.spi: CE2 new window [ 0x24000000 - 0x25ffffff ] 32MB
> [ 13.215962] spi-aspeed-smc 1e620000.spi: calculate timing compensation - AHB freq: 180 MHz
> [ 13.222431] spi-aspeed-smc 1e620000.spi: Trying HCLK/5 [203c0d41] ...
> [ 13.250258] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 4ns DI delay : PASS
> [ 13.278256] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 0ns DI delay : PASS
> [ 13.306252] spi-aspeed-smc 1e620000.spi: * [00000000] 1 HCLK delay, 4ns DI delay : PASS
> [ 13.306337] spi-aspeed-smc 1e620000.spi: * -> good is pass 1 [0x00000000]
> [ 13.306392] spi-aspeed-smc 1e620000.spi: Trying HCLK/4 [203c0641] ...
> [ 13.330735] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 4ns DI delay : PASS
> [ 13.355007] spi-aspeed-smc 1e620000.spi: * [00000000] 0 HCLK delay, 0ns DI delay : PASS
> [ 13.379274] spi-aspeed-smc 1e620000.spi: * [00000000] 1 HCLK delay, 4ns DI delay : PASS
> [ 13.379362] spi-aspeed-smc 1e620000.spi: * -> good is pass 1 [0x00000000]
> [ 13.379416] spi-aspeed-smc 1e620000.spi: Found good read timings at HCLK/4
> [ 13.379465] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
> [ 13.460934] 1 fixed-partitions partitions found on MTD device spi0.1
> [ 13.537042] Creating 1 MTD partitions on "spi0.1":
> [ 14.145255] spi-aspeed-smc 1e620000.spi: registered child spi0.1
> [ 28.287508] SPI driver bmp280 has no spi_device_id for bosch,bmp085
> [ 116.047752] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
> [ 116.047894] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0x44
> [ 116.048011] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
> [ 116.048109] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
> [ 116.048260] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
> [ 116.048363] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0xc
> [ 116.048461] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
> [ 116.049421] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
> [ 116.049559] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0x44
> [ 116.049676] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
> [ 116.049773] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
> [ 116.049872] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
> [ 116.049969] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0x39
> [ 116.050070] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
> [ 116.050159] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
> [ 116.050307] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x6 mode:1.0.0.0 naddr:0x0 ndummies:0x0 len:0x0
> [ 116.050416] spi-aspeed-smc 1e620000.spi: CE0 write OP 0x12 mode:1.1.0.1 naddr:0x4 ndummies:0x0 len:0xc
> [ 116.050513] spi-aspeed-smc 1e620000.spi: CE0 read OP 0x5 mode:1.0.0.1 naddr:0x0 ndummies:0x0 len:0x1
0x12 is "page program". I think that's where the slow down comes from.
you can switch off the logging after boot with :
mount -t debugfs debugfs /sys/kernel/debug/
echo -n "file drivers/spi/* -p" > /sys/kernel/debug/dynamic_debug/control
Thanks a lot for the tests !
C.
>
> Cheers,
>
> Tao
>
> On Wed, Mar 02, 2022 at 07:23:15AM +0100, Cédric Le Goater wrote:
>> Hello Tao,
>>
>> On 3/2/22 07:05, Tao Ren wrote:
>>> Hi Cedric,
>>>
>>> I tested v2 on wedge100 (ast2400) and cmm (ast2500). I don't see any
>>> functional failures except below warning on ast2400.
>>
>> Thanks for the tests
>>
>>> Is it something we should worry about?
>>>
>>>> spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
>>
>>
>> This means that the training failed for all HCLK settings. We never had
>> an AST2400 board with a second device on the FMC controller but we noticed
>> that any freq setting above 50MHz was unstable.
>>
>> Also, aspeed-g4.dtsi does not have any "spi-max-frequency" for flash@1.
>> This needs an update.
>>
>>> The v2 patch series (10 patches) were applied to linux stable 5.15.25,
>>> and below are the outputs on wedge100 (ast2400):
>>>
>>> root@wedge100-bmc:~# dmesg | grep -i spi
>>> [ 11.479736] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
>>> [ 11.704313] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
>>> [ 11.785842] 5 fixed-partitions partitions found on MTD device spi0.0
>>> [ 11.862033] Creating 5 MTD partitions on "spi0.0":
>>> [ 13.039009] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
>>> [ 13.107056] spi-aspeed-smc 1e620000.spi: No good frequency, using dumb slow
>>> [ 13.190551] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0041]
>>> [ 13.271959] 1 fixed-partitions partitions found on MTD device spi0.1
>>> [ 13.348097] Creating 1 MTD partitions on "spi0.1":
>>
>> Curious. The device seems alive and very slow.
>>
>> Could you please add "dyndbg="file drivers/spi/* +p;" to the bootargs
>> and reboot ?
>>
>>
>>> [ 28.169886] SPI driver bmp280 has no spi_device_id for bosch,bmp085
>>> root@wedge100-bmc:/tmp# cat /proc/mtd
>>> dev: size erasesize name
>>> mtd0: 00060000 00010000 "u-boot"
>>> mtd1: 00020000 00010000 "env"
>>> mtd2: 01b80000 00010000 "fit"
>>> mtd3: 00400000 00010000 "data0"
>>> mtd4: 02000000 00010000 "flash0"
>>> mtd5: 02000000 00010000 "flash1"
>>> root@wedge100-bmc:/tmp# ls -l flash-wedge100
>>> -rw-r--r-- 1 root root 22867574 Mar 1 20:49 flash-wedge100
>>> root@wedge100-bmc:/tmp# time flashcp flash-wedge100 /dev/mtd4
>>>
>>> real 2m22.860s
>>> user 0m0.478s
>>> sys 2m10.647s
>>> root@wedge100-bmc:/tmp# ls -l flash-wedge100.v2021.13.1
>>> -rw-r--r-- 1 root root 19743390 Mar 1 10:10 flash-wedge100.v2021.13.1
>>> root@wedge100-bmc:/tmp# time flashcp flash-wedge100.v2021.13.1 /dev/mtd5
>>>
>>> real 2m23.144s
>>> user 0m0.409s
>>> sys 2m10.526s
>>
>> Since spi0.1 seems to be really slow, could you run
>>
>> time mdsum /dev/mtd5
>>
>> and compare with flash-wedge100.v2021.13.1 ? But please update
>> "spi-max-frequency" in the DT first.
>>
>> Thanks,
>>
>> C.
>>
>>>
>>> And here are the outpus on cmm (ast2500):
>>>
>>> root@cmm001-oob:~# dmesg | grep -i spi
>>> [ 15.172879] spi-nor spi0.0: mx25l25635e (32768 Kbytes)
>>> [ 15.361516] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
>>> [ 15.442978] 5 fixed-partitions partitions found on MTD device spi0.0
>>> [ 15.519145] Creating 5 MTD partitions on "spi0.0":
>>> [ 15.883123] spi-nor spi0.1: mx25l25635e (32768 Kbytes)
>>> [ 16.071286] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
>>> [ 16.152711] 1 fixed-partitions partitions found on MTD device spi0.1
>>> [ 16.228830] Creating 1 MTD partitions on "spi0.1":
>>> [ 63.831721] SPI driver bmp280 has no spi_device_id for bosch,bmp085
>>> root@cmm001-oob:/tmp# cat /proc/mtd
>>> dev: size erasesize name
>>> mtd0: 00060000 00001000 "u-boot"
>>> mtd1: 00020000 00001000 "env"
>>> mtd2: 01b80000 00001000 "fit"
>>> mtd3: 00400000 00001000 "data0"
>>> mtd4: 02000000 00001000 "flash0"
>>> mtd5: 02000000 00001000 "flash1"
>>> root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm
>>> -rw-r--r-- 1 root root 23772278 Mar 1 21:04 /tmp/flash-cmm
>>> root@cmm001-oob:/tmp# time flashcp /tmp/flash-cmm /dev/mtd4
>>> real 3m37.154s
>>> user 0m0.260s
>>> sys 3m31.700s
>>> root@cmm001-oob:/tmp# ls -l /tmp/flash-cmm.v2021.48.0
>>> -rw-r--r-- 1 root root 23723958 Mar 1 21:07 /tmp/flash-cmm.v2021.48.0
>>> root@cmm001-oob:/tmp# time flashcp flash-cmm.v2021.48.0 /dev/mtd5
>>>
>>> real 3m33.843s
>>> user 0m0.458s
>>> sys 3m28.216s
>>>
>>>
>>> Cheers,
>>>
>>> Tao
>>>
>>> On Sun, Feb 27, 2022 at 07:53:37PM +0100, Cédric Le Goater wrote:
>>>> On 2/25/22 06:29, Joel Stanley wrote:
>>>>> Cedric has authored a new drive for the SPI NOR devices on the ASPEED
>>>>> SoCs. It supports 2400, 2500 and 2600. It is written using the spi-mem
>>>>> subsystem, which should mean it can go upstream.
>>>>>
>>>>> This is great news, as our current driver is half upstream, half in
>>>>> the openbmc tree, due to some issues getting it merged as part of the
>>>>> spi-nor subsystem.
>>>>>
>>>>> It would be great to have testing. I've created a commit that patches
>>>>> in support to whatever kernel tree you're using. Hopefully this makes
>>>>> it easier to test atop your internal branches:
>>>>>
>>>>> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/51551
>>>>>
>>>>> Cherry pick this commit into your tree, and see how it goes, and report back.
>>>>>
>>>>> I plan to switch the openbmc tree to this driver when we next rebase
>>>>> the kernel. We could also backport it to dev-5.15 as an option.
>>>>>
>>>>> You can direct testing results to this thread, or reply directly to
>>>>> the upstream thread:
>>>>>
>>>>> https://lore.kernel.org/all/20220214094231.3753686-1-clg@kaod.org/
>>>>
>>>> or grab the v2 from :
>>>>
>>>> https://github.com/legoater/linux/tree/openbmc-5.15
>>>>
>>>> I have addressed the comments on driver bind/unbind.
>>>>
>>>> Thanks,
>>>>
>>>> C.
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Joel
>>>>>
>>>>> ---------- Forwarded message ---------
>>>>> From: Cédric Le Goater <clg@kaod.org>
>>>>> Date: Mon, 14 Feb 2022 at 09:42
>>>>> Subject: [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers
>>>>> To: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>
>>>>> Cc: Mark Brown <broonie@kernel.org>, Tudor Ambarus
>>>>> <tudor.ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Miquel
>>>>> Raynal <miquel.raynal@bootlin.com>, Richard Weinberger
>>>>> <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
>>>>> <linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>, Andrew
>>>>> Jeffery <andrew@aj.id.au>, Chin-Ting Kuo
>>>>> <chin-ting_kuo@aspeedtech.com>, <devicetree@vger.kernel.org>, Rob
>>>>> Herring <robh+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
>>>>> <linux-kernel@vger.kernel.org>, Cédric Le Goater <clg@kaod.org>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> This series adds a new SPI driver using the spi-mem interface for the
>>>>> Aspeed static memory controllers of the AST2600, AST2500 and AST2400
>>>>> SoCs.
>>>>>
>>>>> * AST2600 Firmware SPI Memory Controller (FMC)
>>>>> * AST2600 SPI Flash Controller (SPI1 and SPI2)
>>>>> * AST2500 Firmware SPI Memory Controller (FMC)
>>>>> * AST2500 SPI Flash Controller (SPI1 and SPI2)
>>>>> * AST2400 New Static Memory Controller (also referred as FMC)
>>>>> * AST2400 SPI Flash Controller (SPI)
>>>>>
>>>>> It is based on the current OpenBMC kernel driver [1], using directly
>>>>> the MTD SPI-NOR interface and on a patchset [2] previously proposed
>>>>> adding support for the AST2600 only. This driver takes a slightly
>>>>> different approach to cover all 6 controllers.
>>>>>
>>>>> It does not make use of the controller register disabling Address and
>>>>> Data byte lanes because is not available on the AST2400 SoC. We could
>>>>> introduce a specific handler for new features available on recent SoCs
>>>>> if needed. As there is not much difference on performance, the driver
>>>>> chooses the common denominator: "User mode" which has been heavily
>>>>> tested in [1]. "User mode" is also used as a fall back method when
>>>>> flash device mapping window is too small.
>>>>>
>>>>> Problems to address with spi-mem were the configuration of the mapping
>>>>> windows and the calibration of the read timings. The driver handles
>>>>> them in the direct mapping handler when some knowledge on the size of
>>>>> the flash device is know. It is not perfect but not incorrect either.
>>>>> The algorithm is one from [1] because it doesn't require the DMA
>>>>> registers which are not available on all controllers.
>>>>>
>>>>> Direct mapping for writes is not supported (yet). I have seen some
>>>>> corruption with writes and I preferred to use the safer and proven
>>>>> method of the initial driver [1]. We can improve that later.
>>>>>
>>>>> The driver supports Quad SPI RX transfers on the AST2600 SoC but it
>>>>> didn't have the expected results. Therefore it is not activated yet.
>>>>> This needs more tests.
>>>>>
>>>>> The series does not remove the current Aspeed SMC driver but prepares
>>>>> ground for its removal by changing its CONFIG option. This last step
>>>>> can be addressed as a followup when the new driver using the spi-mem
>>>>> interface has been sufficiently exposed.
>>>>>
>>>>> Tested on:
>>>>>
>>>>> * OpenPOWER Palmetto (AST2400)
>>>>> * Evaluation board (AST2500)
>>>>> * OpenPOWER Witherspoon (AST2500)
>>>>> * Evaluation board (AST2600 A0)
>>>>> * Rainier board (AST2600)
>>>>>
>>>>> [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c
>>>>> [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
>>>>>
>>>>> Thanks,
>>>>>
>>>>> C.
>>>>>
>>>>> Cédric Le Goater (10):
>>>>> mtd: spi-nor: aspeed: Rename Kconfig option
>>>>> dt-bindings: spi: Add Aspeed SMC controllers device tree binding
>>>>> spi: spi-mem: Add driver for Aspeed SMC controllers
>>>>> spi: aspeed: Add support for direct mapping
>>>>> spi: aspeed: Adjust direct mapping to device size
>>>>> spi: aspeed: Workaround AST2500 limitations
>>>>> spi: aspeed: Add support for the AST2400 SPI controller
>>>>> spi: aspeed: Calibrate read timings
>>>>> ARM: dts: aspeed: Enable Dual SPI RX transfers
>>>>> spi: aspeed: Activate new spi-mem driver
>>>>>
>>>>> drivers/spi/spi-aspeed-smc.c | 1241 +++++++++++++++++
>>>>> .../bindings/spi/aspeed,ast2600-fmc.yaml | 92 ++
>>>>> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
>>>>> arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
>>>>> arch/arm/boot/dts/aspeed-g6.dtsi | 8 +
>>>>> drivers/mtd/spi-nor/controllers/Kconfig | 4 +-
>>>>> drivers/mtd/spi-nor/controllers/Makefile | 2 +-
>>>>> drivers/spi/Kconfig | 11 +
>>>>> drivers/spi/Makefile | 1 +
>>>>> 9 files changed, 1369 insertions(+), 3 deletions(-)
>>>>> create mode 100644 drivers/spi/spi-aspeed-smc.c
>>>>> create mode 100644
>>>>> Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
>>>>>
>>>>> --
>>>>> 2.34.1
>>>>
>>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-02 5:45 ` Cédric Le Goater
@ 2022-03-03 9:45 ` Joel Stanley
2022-03-03 9:51 ` Cédric Le Goater
0 siblings, 1 reply; 115+ messages in thread
From: Joel Stanley @ 2022-03-03 9:45 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Ryan Chen, OpenBMC Maillist, Lei Yu, John Wang
On Wed, 2 Mar 2022 at 05:45, Cédric Le Goater <clg@kaod.org> wrote:
>
> On 3/1/22 13:20, Joel Stanley wrote:
> > [ 0.746796] spi-nor spi0.0: w25q512jv (65536 Kbytes)
> > [ 0.808104] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
> > [ 0.862687] spi-nor spi0.1: w25q512jv (65536 Kbytes)
> > [ 0.923991] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
>
>
> On the FMC controller, could you please increase the clock to :
>
> spi-max-frequency = <100000000>;
>
> and check the results ?
+++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
@@ -162,7 +162,7 @@ flash@0 {
status = "okay";
m25p,fast-read;
label = "bmc";
- spi-max-frequency = <50000000>;
+ spi-max-frequency = <100000000>;
#include "openbmc-flash-layout-64.dtsi"
};
@@ -170,6 +170,7 @@ flash@1 {
status = "okay";
m25p,fast-read;
label = "alt-bmc";
+ spi-max-frequency = <100000000>;
};
};
# dmesg |grep spi
[ 0.746939] spi-nor spi0.0: w25q512jv (65536 Kbytes)
[ 0.904547] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0741]
[ 0.959048] spi-nor spi0.1: w25q512jv (65536 Kbytes)
[ 1.116603] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0741]
[ 1.130483] spi-nor spi1.0: w25q256 (32768 Kbytes)
[ 1.255015] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
[ 1.269188] spi-nor spi2.0: gd25q256 (32768 Kbytes)
[ 1.366623] spi-aspeed-smc 1e631000.spi: CE0 read buswidth:2 [0x203c0741]
# fdtget /sys/firmware/fdt /ahb/spi@1e620000/flash@0 spi-max-frequency
100000000
# fdtget /sys/firmware/fdt /ahb/spi@1e620000/flash@0 spi-max-frequency
100000000
l# ./mtd-stress.sh mtd5 mtd6
22+0 records in
22+0 records out
23068672 bytes (23 MB, 22 MiB) copied, 2.39988 s, 9.6 MB/s
28deb0d7b7ac61a3a748661d17caad9b /tmp/tmp.F0iA2sCa75
Erasing blocks: 352/352 (100%)
Writing data: 22528k/22528k (100%)
Verifying data: 22528k/22528k (100%)
real 2m51.548s
user 0m0.010s
sys 2m46.316s
28deb0d7b7ac61a3a748661d17caad9b /dev/mtd5
real 0m2.473s
user 0m0.158s
sys 0m2.286s
64+0 records in
64+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 5.34609 s, 12.6 MB/s
33e2d1b6b58feaf69ae03bce376cbad3 /tmp/tmp.bCJiVeGiSh
Erasing blocks: 1024/1024 (100%)
Writing data: 65536k/65536k (100%)
Verifying data: 65536k/65536k (100%)
real 7m50.545s
user 0m0.200s
sys 7m35.033s
33e2d1b6b58feaf69ae03bce376cbad3 /dev/mtd6
real 0m7.187s
user 0m0.485s
sys 0m6.635s
Do we expect it to take the same amount of time?
>
> > [ 0.937639] spi-nor spi1.0: w25q256 (32768 Kbytes)
> > [ 1.062246] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
> > [ 1.076507] spi-nor spi2.0: gd25q256 (32768 Kbytes)
> > [ 1.173951] spi-aspeed-smc 1e631000.spi: CE0 read buswidth:2 [0x203c0741]
> >
> > ./mtd-stress.sh mtd5 mtd6 mtd7 mtd8
>
> A good test would be to read from /dev/mtd0 and reflash the resulting file.
> Keep an external programmer close at hand just in case :)
I did this, while crossing my legs, arms, fingers and toes.
root@apolo:~# ./mtd-stress.sh mtd0
64+0 records in
64+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 5.15611 s, 13.0 MB/s
8a439fdfec504f3e8574c4260d0389ee /tmp/tmp.kbTNY4G8Qd
Erasing blocks: 1024/1024 (100%)
Writing data: 65536k/65536k (100%)
Verifying data: 5590k/65536k (8%)File does not seem to match flash
data. First mismatch at 0x00573000-0x00575800
real 7m56.061s
user 0m0.050s
sys 7m54.697s
343335c0dc778b95afc83a95307921a7 /dev/mtd0
real 0m7.191s
user 0m0.482s
sys 0m6.597s
Oh no! A failure!
I ran it again and it succeeded. Both tests were with random data. I
wrote to it a third time, this time restoring the original file, and
it succeeded.
Cheers,
Joel
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-03 9:45 ` Joel Stanley
@ 2022-03-03 9:51 ` Cédric Le Goater
2022-03-03 9:57 ` Joel Stanley
0 siblings, 1 reply; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-03 9:51 UTC (permalink / raw)
To: Joel Stanley; +Cc: Ryan Chen, OpenBMC Maillist, Lei Yu, John Wang
On 3/3/22 10:45, Joel Stanley wrote:
> On Wed, 2 Mar 2022 at 05:45, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> On 3/1/22 13:20, Joel Stanley wrote:
>
>>> [ 0.746796] spi-nor spi0.0: w25q512jv (65536 Kbytes)
>>> [ 0.808104] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
>>> [ 0.862687] spi-nor spi0.1: w25q512jv (65536 Kbytes)
>>> [ 0.923991] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
>>
>>
>> On the FMC controller, could you please increase the clock to :
>>
>> spi-max-frequency = <100000000>;
>>
>> and check the results ?
>
> +++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> @@ -162,7 +162,7 @@ flash@0 {
> status = "okay";
> m25p,fast-read;
> label = "bmc";
> - spi-max-frequency = <50000000>;
> + spi-max-frequency = <100000000>;
> #include "openbmc-flash-layout-64.dtsi"
> };
>
> @@ -170,6 +170,7 @@ flash@1 {
> status = "okay";
> m25p,fast-read;
> label = "alt-bmc";
> + spi-max-frequency = <100000000>;
> };
> };
>
>
>
> # dmesg |grep spi
> [ 0.746939] spi-nor spi0.0: w25q512jv (65536 Kbytes)
> [ 0.904547] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0741]
> [ 0.959048] spi-nor spi0.1: w25q512jv (65536 Kbytes)
> [ 1.116603] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0741]
> [ 1.130483] spi-nor spi1.0: w25q256 (32768 Kbytes)
> [ 1.255015] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
> [ 1.269188] spi-nor spi2.0: gd25q256 (32768 Kbytes)
> [ 1.366623] spi-aspeed-smc 1e631000.spi: CE0 read buswidth:2 [0x203c0741]
>
> # fdtget /sys/firmware/fdt /ahb/spi@1e620000/flash@0 spi-max-frequency
> 100000000
> # fdtget /sys/firmware/fdt /ahb/spi@1e620000/flash@0 spi-max-frequency
> 100000000
>
> l# ./mtd-stress.sh mtd5 mtd6
> 22+0 records in
> 22+0 records out
> 23068672 bytes (23 MB, 22 MiB) copied, 2.39988 s, 9.6 MB/s
> 28deb0d7b7ac61a3a748661d17caad9b /tmp/tmp.F0iA2sCa75
> Erasing blocks: 352/352 (100%)
> Writing data: 22528k/22528k (100%)
> Verifying data: 22528k/22528k (100%)
>
> real 2m51.548s
> user 0m0.010s
> sys 2m46.316s
> 28deb0d7b7ac61a3a748661d17caad9b /dev/mtd5
>
> real 0m2.473s
> user 0m0.158s
> sys 0m2.286s
> 64+0 records in
> 64+0 records out
> 67108864 bytes (67 MB, 64 MiB) copied, 5.34609 s, 12.6 MB/s
> 33e2d1b6b58feaf69ae03bce376cbad3 /tmp/tmp.bCJiVeGiSh
> Erasing blocks: 1024/1024 (100%)
> Writing data: 65536k/65536k (100%)
> Verifying data: 65536k/65536k (100%)
>
> real 7m50.545s
> user 0m0.200s
> sys 7m35.033s
> 33e2d1b6b58feaf69ae03bce376cbad3 /dev/mtd6
>
> real 0m7.187s
> user 0m0.485s
> sys 0m6.635s
>
>
> Do we expect it to take the same amount of time?
There is a nice boost on the reads. Write are the same but that's expected.
>
>>
>>> [ 0.937639] spi-nor spi1.0: w25q256 (32768 Kbytes)
>>> [ 1.062246] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
>>> [ 1.076507] spi-nor spi2.0: gd25q256 (32768 Kbytes)
>>> [ 1.173951] spi-aspeed-smc 1e631000.spi: CE0 read buswidth:2 [0x203c0741]
>>>
>>> ./mtd-stress.sh mtd5 mtd6 mtd7 mtd8
>>
>> A good test would be to read from /dev/mtd0 and reflash the resulting file.
>> Keep an external programmer close at hand just in case :)
>
> I did this, while crossing my legs, arms, fingers and toes.
>
> root@apolo:~# ./mtd-stress.sh mtd0
> 64+0 records in
> 64+0 records out
> 67108864 bytes (67 MB, 64 MiB) copied, 5.15611 s, 13.0 MB/s
> 8a439fdfec504f3e8574c4260d0389ee /tmp/tmp.kbTNY4G8Qd
> Erasing blocks: 1024/1024 (100%)
> Writing data: 65536k/65536k (100%)
> Verifying data: 5590k/65536k (8%)File does not seem to match flash
> data. First mismatch at 0x00573000-0x00575800
ouch. we should keep the 50MHz value then.
> real 7m56.061s
> user 0m0.050s
> sys 7m54.697s
> 343335c0dc778b95afc83a95307921a7 /dev/mtd0
>
> real 0m7.191s
> user 0m0.482s
> sys 0m6.597s
>
> Oh no! A failure!
>
> I ran it again and it succeeded. Both tests were with random data. I
> wrote to it a third time, this time restoring the original file, and
> it succeeded.
and did you reboot ? :)
Cheers,
C.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-03 9:51 ` Cédric Le Goater
@ 2022-03-03 9:57 ` Joel Stanley
0 siblings, 0 replies; 115+ messages in thread
From: Joel Stanley @ 2022-03-03 9:57 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Ryan Chen, OpenBMC Maillist, Lei Yu, John Wang
On Thu, 3 Mar 2022 at 09:51, Cédric Le Goater <clg@kaod.org> wrote:
> >
> > Oh no! A failure!
> >
> > I ran it again and it succeeded. Both tests were with random data. I
> > wrote to it a third time, this time restoring the original file, and
> > it succeeded.
>
> and did you reboot ? :)
>
Yes. And I've re-flashed cs0 a few times running at 50MHz without issue.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-03 7:02 ` Cédric Le Goater
@ 2022-03-04 7:53 ` Tao Ren
0 siblings, 0 replies; 115+ messages in thread
From: Tao Ren @ 2022-03-04 7:53 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: OpenBMC Maillist, Lei Yu, Ryan Chen, Joel Stanley
Hi Cedric,
On Thu, Mar 03, 2022 at 08:02:58AM +0100, Cédric Le Goater wrote:
> Hello Tao,
>
> On 3/3/22 07:03, Tao Ren wrote:
> > Hi Cedric,
> >
> > The "No good frequency" warning is gone after updating spi-max-frequency
> > to 50MHz in aspeed-g4.dtsi (thanks). I don't see any functional failures,
>
> Super !
>
> May be send the "spi-max-frequency" patch ? I can include it in a v3 if a
> resend is needed.
I just sent you the spi-max-frequency patch in a separate email, and I
also tested the patch with both the legacy mtd/spi-nor and new spi-mem
driver.
Could you please include it in v3 (if re-send is needed)? Otherwise I
will send it after the patches are merged (to avoid merge conflicts).
>
> > but flashcp ran slower compared to the mtd/spi-nor driver(~200 sec vs.
> > ~145 sec when flashcp 32MB data to flash1).
>
> Interesting, the HW settings should be the same. Was the dynamic debug
> activated ?
Thanks for asking. Dynamic debug was disabled while running flashcp
testing, but I just realized the 2 wedge100 switches are using different
flashes (mx25125635e vs. w25q256), so it doesn't make sense to compare
the performance.
I ran more testing on the same ast2400 machine today, and test shows
spi-mem ran slightly faster than the legacy mtd/spi-nor driver. Let me
reduce the other noises (user space apps eating CPU) and will share you
more data later.
But still, no functional issues observed so far. Thank you again for the
patches.
Cheers,
Tao
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-02 2:28 ` [External] " Lei Yu
@ 2022-03-07 9:41 ` Lei Yu
2022-03-07 13:06 ` Cédric Le Goater
0 siblings, 1 reply; 115+ messages in thread
From: Lei Yu @ 2022-03-07 9:41 UTC (permalink / raw)
To: Joel Stanley
Cc: Ryan Chen, OpenBMC Maillist, John Wang, Cédric Le Goater
We hit some issues with the new driver, and here is some detailed info.
* Our system (not yet upstreamed) uses `mx66l51235f` as the FMC SPI
flash, and we created a QEMU model.
* When the dts is like "default":
&fmc {
pinctrl-names = "default";
status = "okay";
flash@0 {
status = "okay";
m25p,fast-read;
label = "bmc";
spi-max-frequency = <50000000>;
#include "openbmc-flash-layout-64.dtsi"
};
};
1. Run the image in ast2600-evb QEMU, it boots fine;
2. We have a model (g220b) in QEMU that uses mx66l51235f as the fmc
SPI (`amc->fmc_model = "mx66l51235f";`), it boots with below error:
[ 1.848286] vmap allocation for size 268439552 failed: use
vmalloc=<size> to increase size
[ 1.848774] spi-aspeed-smc 1e620000.spi: ioremap failed for
resource [mem 0x20000000-0x2fffffff]
[ 1.849898] spi-aspeed-smc: probe of 1e620000.spi failed with error -12
3. If I manually add vmalloc to the kernel command line (setenv
bootargs 'console=ttyS4,115200n8 root=/dev/ram rw vmalloc=400M'), the
above QEMU model boots fine.
4. On the real system, it behaves the same as QEMU, that I need to add
`vmalloc=400M` to make it boot OK.
* When the dts set `spi-tx-bus-width/spi-rx-bus-width = <4>`, and uses
pinctrl_fwqspid_default from @Joel Stanley's pinctrl patch:
&fmc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fwqspid_default>;
status = "okay";
flash@0 {
status = "okay";
m25p,fast-read;
label = "bmc";
spi-max-frequency = <50000000>;
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
#include "openbmc-flash-layout-64.dtsi"
};
};
1. It fails to boot in ast2600-evb QEMU:
[ 0.586654] spi-nor: probe of spi0.0 failed with error -5
[ 0.587654] spi-nor spi0.1: unrecognized JEDEC id bytes: 00 00 00 00 00 00
2. It fails to boot in the g220b model with the same vmalloc failure issue.
2. With `vmalloc=400M`, the g220b model boots fine in QEMU.
3. On the real system, it still fails to boot with `vmalloc=400M` due
to the below error:
[ 0.970091] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff
[ 0.977902] spi-nor: probe of spi0.0 failed with error -2
--
BRs,
Lei YU
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-07 9:41 ` Lei Yu
@ 2022-03-07 13:06 ` Cédric Le Goater
2022-03-08 1:53 ` Lei Yu
0 siblings, 1 reply; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-07 13:06 UTC (permalink / raw)
To: Lei Yu, Joel Stanley; +Cc: Ryan Chen, OpenBMC Maillist, John Wang
Hello,
On 3/7/22 10:41, Lei Yu wrote:
> We hit some issues with the new driver, and here is some detailed info.
>
> * Our system (not yet upstreamed) uses `mx66l51235f` as the FMC SPI
> flash, and we created a QEMU model.
>
> * When the dts is like "default":
> &fmc {
> pinctrl-names = "default";
> status = "okay";
> flash@0 {
> status = "okay";
> m25p,fast-read;
> label = "bmc";
> spi-max-frequency = <50000000>;
> #include "openbmc-flash-layout-64.dtsi"
> };
> };
> 1. Run the image in ast2600-evb QEMU, it boots fine;
> 2. We have a model (g220b) in QEMU that uses mx66l51235f as the fmc
> SPI (`amc->fmc_model = "mx66l51235f";`), it boots with below error:
> [ 1.848286] vmap allocation for size 268439552 failed: use
> vmalloc=<size> to increase size
> [ 1.848774] spi-aspeed-smc 1e620000.spi: ioremap failed for
> resource [mem 0x20000000-0x2fffffff]
> [ 1.849898] spi-aspeed-smc: probe of 1e620000.spi failed with error -12
> 3. If I manually add vmalloc to the kernel command line (setenv
> bootargs 'console=ttyS4,115200n8 root=/dev/ram rw vmalloc=400M'), the
> above QEMU model boots fine.
> 4. On the real system, it behaves the same as QEMU, that I need to add
> `vmalloc=400M` to make it boot OK.
I don't see why. Is that the same kernel version and config ?
May be check the allocations in
/proc/vmallocinfo
> * When the dts set `spi-tx-bus-width/spi-rx-bus-width = <4>`, and uses
> pinctrl_fwqspid_default from @Joel Stanley's pinctrl patch:
> &fmc {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_fwqspid_default>;
> status = "okay";
> flash@0 {
> status = "okay";
> m25p,fast-read;
> label = "bmc";
> spi-max-frequency = <50000000>;
> spi-tx-bus-width = <4>;
> spi-rx-bus-width = <4>;
> #include "openbmc-flash-layout-64.dtsi"
> };
> };
> 1. It fails to boot in ast2600-evb QEMU:
> [ 0.586654] spi-nor: probe of spi0.0 failed with error -5
> [ 0.587654] spi-nor spi0.1: unrecognized JEDEC id bytes: 00 00 00 00 00 00
> 2. It fails to boot in the g220b model with the same vmalloc failure issue.
> 2. With `vmalloc=400M`, the g220b model boots fine in QEMU.
> 3. On the real system, it still fails to boot with `vmalloc=400M` due
> to the below error:
> [ 0.970091] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff
> [ 0.977902] spi-nor: probe of spi0.0 failed with error -2
I could not make Quad work reliably on HW. This is the next step after the
new driver is merged.
Thanks for tests !
C.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-07 13:06 ` Cédric Le Goater
@ 2022-03-08 1:53 ` Lei Yu
2022-03-08 9:30 ` Cédric Le Goater
0 siblings, 1 reply; 115+ messages in thread
From: Lei Yu @ 2022-03-08 1:53 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Ryan Chen, OpenBMC Maillist, John Wang
On Mon, Mar 7, 2022 at 9:06 PM Cédric Le Goater <clg@kaod.org> wrote:
>
> Hello,
>
> On 3/7/22 10:41, Lei Yu wrote:
> > We hit some issues with the new driver, and here is some detailed info.
> >
> > * Our system (not yet upstreamed) uses `mx66l51235f` as the FMC SPI
> > flash, and we created a QEMU model.
> >
> > * When the dts is like "default":
> > &fmc {
> > pinctrl-names = "default";
> > status = "okay";
> > flash@0 {
> > status = "okay";
> > m25p,fast-read;
> > label = "bmc";
> > spi-max-frequency = <50000000>;
> > #include "openbmc-flash-layout-64.dtsi"
> > };
> > };
> > 1. Run the image in ast2600-evb QEMU, it boots fine;
> > 2. We have a model (g220b) in QEMU that uses mx66l51235f as the fmc
> > SPI (`amc->fmc_model = "mx66l51235f";`), it boots with below error:
> > [ 1.848286] vmap allocation for size 268439552 failed: use
> > vmalloc=<size> to increase size
> > [ 1.848774] spi-aspeed-smc 1e620000.spi: ioremap failed for
> > resource [mem 0x20000000-0x2fffffff]
> > [ 1.849898] spi-aspeed-smc: probe of 1e620000.spi failed with error -12
> > 3. If I manually add vmalloc to the kernel command line (setenv
> > bootargs 'console=ttyS4,115200n8 root=/dev/ram rw vmalloc=400M'), the
> > above QEMU model boots fine.
> > 4. On the real system, it behaves the same as QEMU, that I need to add
> > `vmalloc=400M` to make it boot OK.
>
> I don't see why. Is that the same kernel version and config ?
>
> May be check the allocations in
>
> /proc/vmallocinfo
It shows a large area as below:
0xc1d30472-0x406b4a0c 268439552 __devm_ioremap_resource+0x178/0x1f0
phys=0x20000000 ioremap
>
> > * When the dts set `spi-tx-bus-width/spi-rx-bus-width = <4>`, and uses
> > pinctrl_fwqspid_default from @Joel Stanley's pinctrl patch:
> > &fmc {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_fwqspid_default>;
> > status = "okay";
> > flash@0 {
> > status = "okay";
> > m25p,fast-read;
> > label = "bmc";
> > spi-max-frequency = <50000000>;
> > spi-tx-bus-width = <4>;
> > spi-rx-bus-width = <4>;
> > #include "openbmc-flash-layout-64.dtsi"
> > };
> > };
> > 1. It fails to boot in ast2600-evb QEMU:
> > [ 0.586654] spi-nor: probe of spi0.0 failed with error -5
> > [ 0.587654] spi-nor spi0.1: unrecognized JEDEC id bytes: 00 00 00 00 00 00
> > 2. It fails to boot in the g220b model with the same vmalloc failure issue.
> > 2. With `vmalloc=400M`, the g220b model boots fine in QEMU.
> > 3. On the real system, it still fails to boot with `vmalloc=400M` due
> > to the below error:
> > [ 0.970091] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff
> > [ 0.977902] spi-nor: probe of spi0.0 failed with error -2
>
>
> I could not make Quad work reliably on HW. This is the next step after the
> new driver is merged.
Got it.
>
> Thanks for tests !
>
> C.
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-08 1:53 ` Lei Yu
@ 2022-03-08 9:30 ` Cédric Le Goater
2022-03-08 9:47 ` Lei Yu
0 siblings, 1 reply; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-08 9:30 UTC (permalink / raw)
To: Lei Yu; +Cc: Ryan Chen, OpenBMC Maillist, John Wang
Hello Lei,
On 3/8/22 02:53, Lei Yu wrote:
> On Mon, Mar 7, 2022 at 9:06 PM Cédric Le Goater <clg@kaod.org> wrote:
>>
>> Hello,
>>
>> On 3/7/22 10:41, Lei Yu wrote:
>>> We hit some issues with the new driver, and here is some detailed info.
>>>
>>> * Our system (not yet upstreamed) uses `mx66l51235f` as the FMC SPI
>>> flash, and we created a QEMU model.
>>>
>>> * When the dts is like "default":
>>> &fmc {
>>> pinctrl-names = "default";
>>> status = "okay";
>>> flash@0 {
>>> status = "okay";
>>> m25p,fast-read;
>>> label = "bmc";
>>> spi-max-frequency = <50000000>;
>>> #include "openbmc-flash-layout-64.dtsi"
>>> };
>>> };
>>> 1. Run the image in ast2600-evb QEMU, it boots fine;
>>> 2. We have a model (g220b) in QEMU that uses mx66l51235f as the fmc
>>> SPI (`amc->fmc_model = "mx66l51235f";`), it boots with below error:
>>> [ 1.848286] vmap allocation for size 268439552 failed: use
>>> vmalloc=<size> to increase size
>>> [ 1.848774] spi-aspeed-smc 1e620000.spi: ioremap failed for
>>> resource [mem 0x20000000-0x2fffffff]
>>> [ 1.849898] spi-aspeed-smc: probe of 1e620000.spi failed with error -12
>>> 3. If I manually add vmalloc to the kernel command line (setenv
>>> bootargs 'console=ttyS4,115200n8 root=/dev/ram rw vmalloc=400M'), the
>>> above QEMU model boots fine.
>>> 4. On the real system, it behaves the same as QEMU, that I need to add
>>> `vmalloc=400M` to make it boot OK.
>>
>> I don't see why. Is that the same kernel version and config ?
>>
>> May be check the allocations in
>>
>> /proc/vmallocinfo
>
> It shows a large area as below:
>
> 0xc1d30472-0x406b4a0c 268439552 __devm_ioremap_resource+0x178/0x1f0
> phys=0x20000000 ioremap
Is CONFIG_VMSPLIT_2G set ?
>
>>
>>> * When the dts set `spi-tx-bus-width/spi-rx-bus-width = <4>`, and uses
>>> pinctrl_fwqspid_default from @Joel Stanley's pinctrl patch:
>>> &fmc {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&pinctrl_fwqspid_default>;
>>> status = "okay";
>>> flash@0 {
>>> status = "okay";
>>> m25p,fast-read;
>>> label = "bmc";
>>> spi-max-frequency = <50000000>;
>>> spi-tx-bus-width = <4>;
>>> spi-rx-bus-width = <4>;
>>> #include "openbmc-flash-layout-64.dtsi"
>>> };
>>> };
>>> 1. It fails to boot in ast2600-evb QEMU:
>>> [ 0.586654] spi-nor: probe of spi0.0 failed with error -5
>>> [ 0.587654] spi-nor spi0.1: unrecognized JEDEC id bytes: 00 00 00 00 00 00
>>> 2. It fails to boot in the g220b model with the same vmalloc failure issue.
>>> 2. With `vmalloc=400M`, the g220b model boots fine in QEMU.
>>> 3. On the real system, it still fails to boot with `vmalloc=400M` due
>>> to the below error:
>>> [ 0.970091] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff
>>> [ 0.977902] spi-nor: probe of spi0.0 failed with error -2
>>
>>
>> I could not make Quad work reliably on HW. This is the next step after the
>> new driver is merged.
>
> Got it.
People are looking into it. When fixed, activating Quad should only be
a DT change.
Thanks,
C.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-08 9:30 ` Cédric Le Goater
@ 2022-03-08 9:47 ` Lei Yu
2022-03-08 14:57 ` Cédric Le Goater
0 siblings, 1 reply; 115+ messages in thread
From: Lei Yu @ 2022-03-08 9:47 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Ryan Chen, OpenBMC Maillist, John Wang
On Tue, Mar 8, 2022 at 5:30 PM Cédric Le Goater <clg@kaod.org> wrote:
>
> Hello Lei,
>
> On 3/8/22 02:53, Lei Yu wrote:
> > On Mon, Mar 7, 2022 at 9:06 PM Cédric Le Goater <clg@kaod.org> wrote:
> >>
> >> Hello,
> >>
> >> On 3/7/22 10:41, Lei Yu wrote:
> >>> We hit some issues with the new driver, and here is some detailed info.
> >>>
> >>> * Our system (not yet upstreamed) uses `mx66l51235f` as the FMC SPI
> >>> flash, and we created a QEMU model.
> >>>
> >>> * When the dts is like "default":
> >>> &fmc {
> >>> pinctrl-names = "default";
> >>> status = "okay";
> >>> flash@0 {
> >>> status = "okay";
> >>> m25p,fast-read;
> >>> label = "bmc";
> >>> spi-max-frequency = <50000000>;
> >>> #include "openbmc-flash-layout-64.dtsi"
> >>> };
> >>> };
> >>> 1. Run the image in ast2600-evb QEMU, it boots fine;
> >>> 2. We have a model (g220b) in QEMU that uses mx66l51235f as the fmc
> >>> SPI (`amc->fmc_model = "mx66l51235f";`), it boots with below error:
> >>> [ 1.848286] vmap allocation for size 268439552 failed: use
> >>> vmalloc=<size> to increase size
> >>> [ 1.848774] spi-aspeed-smc 1e620000.spi: ioremap failed for
> >>> resource [mem 0x20000000-0x2fffffff]
> >>> [ 1.849898] spi-aspeed-smc: probe of 1e620000.spi failed with error -12
> >>> 3. If I manually add vmalloc to the kernel command line (setenv
> >>> bootargs 'console=ttyS4,115200n8 root=/dev/ram rw vmalloc=400M'), the
> >>> above QEMU model boots fine.
> >>> 4. On the real system, it behaves the same as QEMU, that I need to add
> >>> `vmalloc=400M` to make it boot OK.
> >>
> >> I don't see why. Is that the same kernel version and config ?
> >>
> >> May be check the allocations in
> >>
> >> /proc/vmallocinfo
> >
> > It shows a large area as below:
> >
> > 0xc1d30472-0x406b4a0c 268439552 __devm_ioremap_resource+0x178/0x1f0
> > phys=0x20000000 ioremap
>
> Is CONFIG_VMSPLIT_2G set ?
Yes, it's enabled in aspeed-g6/defconfig
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-08 9:47 ` Lei Yu
@ 2022-03-08 14:57 ` Cédric Le Goater
2022-03-09 1:58 ` Lei Yu
0 siblings, 1 reply; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-08 14:57 UTC (permalink / raw)
To: Lei Yu; +Cc: Ryan Chen, OpenBMC Maillist, John Wang
On 3/8/22 10:47, Lei Yu wrote:
> On Tue, Mar 8, 2022 at 5:30 PM Cédric Le Goater <clg@kaod.org> wrote:
>>
>> Hello Lei,
>>
>> On 3/8/22 02:53, Lei Yu wrote:
>>> On Mon, Mar 7, 2022 at 9:06 PM Cédric Le Goater <clg@kaod.org> wrote:
>>>>
>>>> Hello,
>>>>
>>>> On 3/7/22 10:41, Lei Yu wrote:
>>>>> We hit some issues with the new driver, and here is some detailed info.
>>>>>
>>>>> * Our system (not yet upstreamed) uses `mx66l51235f` as the FMC SPI
>>>>> flash, and we created a QEMU model.
>>>>>
>>>>> * When the dts is like "default":
>>>>> &fmc {
>>>>> pinctrl-names = "default";
>>>>> status = "okay";
>>>>> flash@0 {
>>>>> status = "okay";
>>>>> m25p,fast-read;
>>>>> label = "bmc";
>>>>> spi-max-frequency = <50000000>;
>>>>> #include "openbmc-flash-layout-64.dtsi"
>>>>> };
>>>>> };
>>>>> 1. Run the image in ast2600-evb QEMU, it boots fine;
>>>>> 2. We have a model (g220b) in QEMU that uses mx66l51235f as the fmc
>>>>> SPI (`amc->fmc_model = "mx66l51235f";`), it boots with below error:
>>>>> [ 1.848286] vmap allocation for size 268439552 failed: use
>>>>> vmalloc=<size> to increase size
>>>>> [ 1.848774] spi-aspeed-smc 1e620000.spi: ioremap failed for
>>>>> resource [mem 0x20000000-0x2fffffff]
>>>>> [ 1.849898] spi-aspeed-smc: probe of 1e620000.spi failed with error -12
>>>>> 3. If I manually add vmalloc to the kernel command line (setenv
>>>>> bootargs 'console=ttyS4,115200n8 root=/dev/ram rw vmalloc=400M'), the
>>>>> above QEMU model boots fine.
>>>>> 4. On the real system, it behaves the same as QEMU, that I need to add
>>>>> `vmalloc=400M` to make it boot OK.
>>>>
>>>> I don't see why. Is that the same kernel version and config ?
>>>>
>>>> May be check the allocations in
>>>>
>>>> /proc/vmallocinfo
>>>
>>> It shows a large area as below:
>>>
>>> 0xc1d30472-0x406b4a0c 268439552 __devm_ioremap_resource+0x178/0x1f0
>>> phys=0x20000000 ioremap
>>
>> Is CONFIG_VMSPLIT_2G set ?
>
> Yes, it's enabled in aspeed-g6/defconfig
The OpenBMC tree only has a aspeed_g5_defconfig.
How much RAM do you have ? Could check the totals in meminfo ?
Thanks,
C.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-08 14:57 ` Cédric Le Goater
@ 2022-03-09 1:58 ` Lei Yu
2022-03-09 7:40 ` Cédric Le Goater
0 siblings, 1 reply; 115+ messages in thread
From: Lei Yu @ 2022-03-09 1:58 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Ryan Chen, OpenBMC Maillist, John Wang
> >>>>
> >>>> I don't see why. Is that the same kernel version and config ?
> >>>>
> >>>> May be check the allocations in
> >>>>
> >>>> /proc/vmallocinfo
> >>>
> >>> It shows a large area as below:
> >>>
> >>> 0xc1d30472-0x406b4a0c 268439552 __devm_ioremap_resource+0x178/0x1f0
> >>> phys=0x20000000 ioremap
> >>
> >> Is CONFIG_VMSPLIT_2G set ?
> >
> > Yes, it's enabled in aspeed-g6/defconfig
>
> The OpenBMC tree only has a aspeed_g5_defconfig.
It does have aspeed-g6/defconfig and CONFIG_VMSPLIT_2G is enabled:
https://github.com/openbmc/openbmc/blob/master/meta-aspeed/recipes-kernel/linux/linux-aspeed/aspeed-g6/defconfig#L33
>
> How much RAM do you have ? Could check the totals in meminfo ?
Our system (and QEMU model) has 2GiB.
Boot with `vmalloc=500M`:
# cat /proc/meminfo
MemTotal: 1984880 kB
MemFree: 1860700 kB
MemAvailable: 1882116 kB
Buffers: 0 kB
Cached: 63796 kB
SwapCached: 0 kB
Active: 13728 kB
Inactive: 71988 kB
Active(anon): 340 kB
Inactive(anon): 37012 kB
Active(file): 13388 kB
Inactive(file): 34976 kB
Unevictable: 3624 kB
Mlocked: 0 kB
HighTotal: 446464 kB
HighFree: 353148 kB
LowTotal: 1538416 kB
LowFree: 1507552 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 25600 kB
Mapped: 40356 kB
Shmem: 11804 kB
KReclaimable: 7712 kB
Slab: 17944 kB
SReclaimable: 7712 kB
SUnreclaim: 10232 kB
KernelStack: 872 kB
PageTables: 2080 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 992440 kB
Committed_AS: 105768 kB
VmallocTotal: 516096 kB
VmallocUsed: 2436 kB
VmallocChunk: 0 kB
Percpu: 232 kB
CmaTotal: 65536 kB
CmaFree: 65052 kB
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-09 1:58 ` Lei Yu
@ 2022-03-09 7:40 ` Cédric Le Goater
2022-03-09 7:50 ` Cédric Le Goater
0 siblings, 1 reply; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-09 7:40 UTC (permalink / raw)
To: Lei Yu; +Cc: Ryan Chen, OpenBMC Maillist, John Wang, Joel Stanley
On 3/9/22 02:58, Lei Yu wrote:
>>>>>>
>>>>>> I don't see why. Is that the same kernel version and config ?
>>>>>>
>>>>>> May be check the allocations in
>>>>>>
>>>>>> /proc/vmallocinfo
>>>>>
>>>>> It shows a large area as below:
>>>>>
>>>>> 0xc1d30472-0x406b4a0c 268439552 __devm_ioremap_resource+0x178/0x1f0
>>>>> phys=0x20000000 ioremap
>>>>
>>>> Is CONFIG_VMSPLIT_2G set ?
>>>
>>> Yes, it's enabled in aspeed-g6/defconfig
>>
>> The OpenBMC tree only has a aspeed_g5_defconfig.
>
> It does have aspeed-g6/defconfig and CONFIG_VMSPLIT_2G is enabled:
> https://github.com/openbmc/openbmc/blob/master/meta-aspeed/recipes-kernel/linux/linux-aspeed/aspeed-g6/defconfig#L33
ok. I was referring to the default configs in the kernel tree.
That's fine.
>>
>> How much RAM do you have ? Could check the totals in meminfo ?
>
> Our system (and QEMU model) has 2GiB.
ah. you changed the default. Here is why we didn't merge the AST2600
with 2GB :
https://lists.nongnu.org/archive/html/qemu-devel/2019-10/msg03903.html
>
> Boot with `vmalloc=500M`:
> # cat /proc/meminfo
> MemTotal: 1984880 kB
> MemFree: 1860700 kB
> MemAvailable: 1882116 kB
That's the reason. The vmalloc area size is in direct relation with
the available RAM. See the ARM memory layout :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/memory.rst
May be we should consider 64-bit kernel one day.
Thanks,
C.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Call for testing: spi-mem driver for Aspeed SMC controllers
2022-03-09 7:40 ` Cédric Le Goater
@ 2022-03-09 7:50 ` Cédric Le Goater
0 siblings, 0 replies; 115+ messages in thread
From: Cédric Le Goater @ 2022-03-09 7:50 UTC (permalink / raw)
To: Lei Yu; +Cc: John Wang, OpenBMC Maillist, Ryan Chen, Joel Stanley
On 3/9/22 08:40, Cédric Le Goater wrote:
> On 3/9/22 02:58, Lei Yu wrote:
>>>>>>>
>>>>>>> I don't see why. Is that the same kernel version and config ?
>>>>>>>
>>>>>>> May be check the allocations in
>>>>>>>
>>>>>>> /proc/vmallocinfo
>>>>>>
>>>>>> It shows a large area as below:
>>>>>>
>>>>>> 0xc1d30472-0x406b4a0c 268439552 __devm_ioremap_resource+0x178/0x1f0
>>>>>> phys=0x20000000 ioremap
>>>>>
>>>>> Is CONFIG_VMSPLIT_2G set ?
>>>>
>>>> Yes, it's enabled in aspeed-g6/defconfig
>>>
>>> The OpenBMC tree only has a aspeed_g5_defconfig.
>>
>> It does have aspeed-g6/defconfig and CONFIG_VMSPLIT_2G is enabled:
>> https://github.com/openbmc/openbmc/blob/master/meta-aspeed/recipes-kernel/linux/linux-aspeed/aspeed-g6/defconfig#L33
>
> ok. I was referring to the default configs in the kernel tree.
> That's fine.
>
>>>
>>> How much RAM do you have ? Could check the totals in meminfo ?
>>
>> Our system (and QEMU model) has 2GiB.
>
> ah. you changed the default. Here is why we didn't merge the AST2600
> with 2GB :
>
> https://lists.nongnu.org/archive/html/qemu-devel/2019-10/msg03903.html
>
>>
>> Boot with `vmalloc=500M`:
>> # cat /proc/meminfo
>> MemTotal: 1984880 kB
>> MemFree: 1860700 kB
>> MemAvailable: 1882116 kB
>
> That's the reason. The vmalloc area size is in direct relation with
> the available RAM. See the ARM memory layout :
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/memory.rst
>
> May be we should consider 64-bit kernel one day.
No. We can't. It's a ARM A7 32-bit. Next Generation then.
C.
^ permalink raw reply [flat|nested] 115+ messages in thread
end of thread, other threads:[~2022-03-09 7:51 UTC | newest]
Thread overview: 115+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-14 9:42 [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` [PATCH 01/10] mtd: spi-nor: aspeed: Rename Kconfig option Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-25 7:31 ` Pratyush Yadav
2022-02-25 7:31 ` Pratyush Yadav
2022-02-25 7:31 ` Pratyush Yadav
2022-02-27 18:50 ` Cédric Le Goater
2022-02-27 18:50 ` Cédric Le Goater
2022-02-27 18:50 ` Cédric Le Goater
2022-02-28 6:07 ` Joel Stanley
2022-02-28 6:07 ` Joel Stanley
2022-02-28 6:07 ` Joel Stanley
2022-02-28 14:37 ` Cédric Le Goater
2022-02-28 14:37 ` Cédric Le Goater
2022-02-28 14:37 ` Cédric Le Goater
2022-02-14 9:42 ` [PATCH 02/10] dt-bindings: spi: Add Aspeed SMC controllers device tree binding Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-15 19:49 ` Rob Herring
2022-02-15 19:49 ` Rob Herring
2022-02-15 19:49 ` Rob Herring
2022-02-15 21:06 ` Rob Herring
2022-02-15 21:06 ` Rob Herring
2022-02-15 21:06 ` Rob Herring
2022-02-17 8:37 ` Cédric Le Goater
2022-02-17 8:37 ` Cédric Le Goater
2022-02-17 8:37 ` Cédric Le Goater
2022-02-14 9:42 ` [PATCH 03/10] spi: spi-mem: Add driver for Aspeed SMC controllers Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-15 6:27 ` Lukas Wunner
2022-02-15 9:07 ` Cédric Le Goater
2022-02-15 9:07 ` Cédric Le Goater
2022-02-15 9:07 ` Cédric Le Goater
2022-02-25 7:50 ` Pratyush Yadav
2022-02-25 7:50 ` Pratyush Yadav
2022-02-25 7:50 ` Pratyush Yadav
2022-02-27 18:46 ` Cédric Le Goater
2022-02-27 18:46 ` Cédric Le Goater
2022-02-27 18:46 ` Cédric Le Goater
2022-02-14 9:42 ` [PATCH 04/10] spi: aspeed: Add support for direct mapping Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-25 9:12 ` Pratyush Yadav
2022-02-25 9:12 ` Pratyush Yadav
2022-02-25 9:12 ` Pratyush Yadav
2022-02-27 21:06 ` Cédric Le Goater
2022-02-27 21:06 ` Cédric Le Goater
2022-02-27 21:06 ` Cédric Le Goater
2022-02-14 9:42 ` [PATCH 05/10] spi: aspeed: Adjust direct mapping to device size Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` [PATCH 06/10] spi: aspeed: Workaround AST2500 limitations Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` [PATCH 07/10] spi: aspeed: Add support for the AST2400 SPI controller Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` [PATCH 08/10] spi: aspeed: Calibrate read timings Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-25 9:18 ` Pratyush Yadav
2022-02-25 9:18 ` Pratyush Yadav
2022-02-25 9:18 ` Pratyush Yadav
2022-02-27 21:27 ` Cédric Le Goater
2022-02-27 21:27 ` Cédric Le Goater
2022-02-27 21:27 ` Cédric Le Goater
2022-02-14 9:42 ` [PATCH 09/10] ARM: dts: aspeed: Enable Dual SPI RX transfers Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-16 7:21 ` Joel Stanley
2022-02-16 7:21 ` Joel Stanley
2022-02-16 7:21 ` Joel Stanley
2022-02-14 9:42 ` [PATCH 10/10] spi: aspeed: Activate new spi-mem driver Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-14 9:42 ` Cédric Le Goater
2022-02-16 7:02 ` Joel Stanley
2022-02-16 7:02 ` Joel Stanley
2022-02-16 7:02 ` Joel Stanley
2022-02-16 8:12 ` Cédric Le Goater
2022-02-16 8:12 ` Cédric Le Goater
2022-02-16 8:12 ` Cédric Le Goater
2022-02-16 7:21 ` [PATCH 00/10] spi: spi-mem: Add driver for Aspeed SMC controllers Joel Stanley
2022-02-16 7:21 ` Joel Stanley
2022-02-16 7:21 ` Joel Stanley
2022-02-25 5:29 ` Call for testing: spi-mem " Joel Stanley
2022-02-27 18:53 ` Cédric Le Goater
2022-02-28 6:30 ` Tao Ren
2022-03-02 6:05 ` Tao Ren
2022-03-02 6:23 ` Cédric Le Goater
2022-03-02 6:47 ` Tao Ren
2022-03-03 6:03 ` Tao Ren
2022-03-03 7:02 ` Cédric Le Goater
2022-03-04 7:53 ` Tao Ren
2022-03-01 9:57 ` John Wang
2022-03-01 10:25 ` Cédric Le Goater
2022-03-02 2:47 ` John Wang
2022-03-01 12:20 ` Joel Stanley
2022-03-02 2:28 ` [External] " Lei Yu
2022-03-07 9:41 ` Lei Yu
2022-03-07 13:06 ` Cédric Le Goater
2022-03-08 1:53 ` Lei Yu
2022-03-08 9:30 ` Cédric Le Goater
2022-03-08 9:47 ` Lei Yu
2022-03-08 14:57 ` Cédric Le Goater
2022-03-09 1:58 ` Lei Yu
2022-03-09 7:40 ` Cédric Le Goater
2022-03-09 7:50 ` Cédric Le Goater
2022-03-02 5:45 ` Cédric Le Goater
2022-03-03 9:45 ` Joel Stanley
2022-03-03 9:51 ` Cédric Le Goater
2022-03-03 9:57 ` Joel Stanley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.