[PATCH v6] spi: orion.c: Add direct access mode

[PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

This patch adds support for the direct write mode to the Orion SPI
driver which is used on the Marvell Armada based SoCs. In this direct
mode, all data written to (or read from) a specifically mapped MBus
window (linked to one SPI chip-select on one of the SPI controllers)
will be transferred directly to the SPI bus. Without the need to control
the SPI registers in between. This can improve the SPI transfer rate in
such cases.

Currently only the direct write mode is supported. This mode especially
benefits from the SPI direct mode, as the data bytes are written
head-to-head to the SPI bus, without any additional addresses, that
are also written in the direct read mode.

One use-case for this direct write mode is, programming a FPGA bitstream
image into the FPGA connected to the SPI bus at maximum speed.

This mode is described in chapter "22.5.2 Direct Write to SPI" in the
Marvell Armada XP Functional Spec Datasheet.

It should be possible to support SPI-NOR and SPI-NAND devices via
this direct access mode as well. But this needs further work, e.g.:
- The mapping of the MBus window needs to get extended to span
  the complete flash device size
- The address / control data needs to get inserted into the SPI
  controller registers

Signed-off-by: Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>
Cc: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
v6:
- Switched from memcpy() to writesl() for the TX transfer.
- Only one page is mapped via ioremap as this is sufficient for
  the currently implemented simple TX transfer.
- Removed max_transfer_size() as its not needed with the current
  one page mapping that supports an unlimited amount of SPI data.
- Added a comment to the 'reg' description in the DT bindings
  documentation as suggested by Arnd.
- Changed 'reg' and 'ranges' to use '<' and '>' in this file.
- Changed size to 0xffffffff in this file.
- Added a small paragraph to the commit text, describing the
  possibility to support SPI-NOR & SPI-NAND devices via this
  direct access mode.

v5:
- Added some documentation for the direct mode to the orion-spi DT
  bindings document, including an example and a reference to the
  mbus DT bindings documentation.

v4:
- Add max_transfer_size()
- Fall back from direct-write mode to PIO mode when
  - transfer size is exceedeed
  - non-8bit transfers
- Restrict to direct-write mode for now. SPI direct read mode can
  be added later, when someone has a platform supporting this
  mode.

v3:
- Used static MBus windows again, as suggested by Arnd
- No new DT bindings needed for this. The MBus windows need to be
  configured in the 'reg' property of the SPI controller. This is
  done in a separate patch for the Armada platforms.
- The direct mapping is configured and enable by adding the
  specific MBus entry to the 'ranges' property of the 'soc' node
  in the board dts file.

v2:
- Use one MBus window for each SPI controller instead of one for
  for each SPI device. This MBus window is re-assigned, once the
  CS changes.
- Assert the CS over the entire message
- Don't restrict the direct access mode to only direct write mode
- Add check for max size before using memcpy()
- Remove spidev from DT bindings documentation

 .../devicetree/bindings/spi/spi-orion.txt          | 49 +++++++++++++-
 drivers/spi/spi-orion.c                            | 79 ++++++++++++++++++++++
 2 files changed, 127 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
index 98bc698..4f629cc 100644
--- a/Documentation/devicetree/bindings/spi/spi-orion.txt
+++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
@@ -8,7 +8,15 @@ Required properties:
     - "marvell,armada-380-spi", for the Armada 38x SoCs
     - "marvell,armada-390-spi", for the Armada 39x SoCs
     - "marvell,armada-xp-spi", for the Armada XP SoCs
-- reg : offset and length of the register set for the device
+- reg : offset and length of the register set for the device.
+	This property can optionally have additional entries to configure
+	the SPI direct access mode that some of the Marvell SoCs support
+	additionally to the normal indirect access (PIO) mode. The values
+	for the MBus "target" and "attribute" are defined in the Marvell
+	SoC "Functional Specifications" Manual in the chapter "Marvell
+	Core Processor Address Decoding".
+	The eight register sets following the control registers refer to
+	chip-select lines 0 through 7 respectively.
 - cell-index : Which of multiple SPI controllers is this.
 Optional properties:
 - interrupts : Is currently not used.
@@ -23,3 +31,42 @@ Example:
 	       interrupts = <23>;
 	       status = "disabled";
        };
+
+Example with SPI direct mode support (optionally):
+	spi0: spi@10600 {
+		compatible = "marvell,orion-spi";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cell-index = <0>;
+		reg = <MBUS_ID(0xf0, 0x01) 0x10600 0x28>, /* control */
+		      <MBUS_ID(0x01, 0x1e) 0 0xffffffff>, /* CS0 */
+		      <MBUS_ID(0x01, 0x5e) 0 0xffffffff>, /* CS1 */
+		      <MBUS_ID(0x01, 0x9e) 0 0xffffffff>, /* CS2 */
+		      <MBUS_ID(0x01, 0xde) 0 0xffffffff>, /* CS3 */
+		      <MBUS_ID(0x01, 0x1f) 0 0xffffffff>, /* CS4 */
+		      <MBUS_ID(0x01, 0x5f) 0 0xffffffff>, /* CS5 */
+		      <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */
+		      <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */
+		interrupts = <23>;
+		status = "disabled";
+	};
+
+To enable the direct mode, the board specific 'ranges' property in the
+'soc' node needs to add the entries for the desired SPI controllers
+and its chip-selects that are used in the direct mode instead of PIO
+mode. Here an example for this (SPI controller 0, device 1 and SPI
+controller 1, device 2 are used in direct mode. All other SPI device
+are used in the default indirect (PIO) mode):
+	soc {
+		/*
+		 * Enable the SPI direct access by configuring an entry
+		 * here in the board-specific ranges property
+		 */
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000>,	/* internal regs */
+			 <MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>,	/* BootROM       */
+			 <MBUS_ID(0x01, 0x5e) 0 0 0xf1100000 0x10000>,	/* SPI0-DEV1 */
+			 <MBUS_ID(0x01, 0x9a) 0 0 0xf1110000 0x10000>;	/* SPI1-DEV2 */
+
+For further information on the MBus bindings, please see the MBus
+DT documentation:
+Documentation/devicetree/bindings/bus/mvebu-mbus.txt
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index a87cfd4..3e20afd 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -18,6 +18,7 @@
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/clk.h>
 #include <linux/sizes.h>
@@ -43,6 +44,9 @@
 #define ORION_SPI_INT_CAUSE_REG		0x10
 #define ORION_SPI_TIMING_PARAMS_REG	0x18
 
+/* Register for the "Direct Mode" */
+#define SPI_DIRECT_WRITE_CONFIG_REG	0x20
+
 #define ORION_SPI_TMISO_SAMPLE_MASK	(0x3 << 6)
 #define ORION_SPI_TMISO_SAMPLE_1	(1 << 6)
 #define ORION_SPI_TMISO_SAMPLE_2	(2 << 6)
@@ -78,11 +82,18 @@ struct orion_spi_dev {
 	bool			is_errata_50mhz_ac;
 };
 
+struct orion_direct_acc {
+	void __iomem		*vaddr;
+	u32			size;
+};
+
 struct orion_spi {
 	struct spi_master	*master;
 	void __iomem		*base;
 	struct clk              *clk;
 	const struct orion_spi_dev *devdata;
+
+	struct orion_direct_acc	direct_access[ORION_NUM_CHIPSELECTS];
 };
 
 static inline void __iomem *spi_reg(struct orion_spi *orion_spi, u32 reg)
@@ -372,10 +383,30 @@ orion_spi_write_read(struct spi_device *spi, struct spi_transfer *xfer)
 {
 	unsigned int count;
 	int word_len;
+	struct orion_spi *orion_spi;
+	int cs = spi->chip_select;
 
 	word_len = spi->bits_per_word;
 	count = xfer->len;
 
+	orion_spi = spi_master_get_devdata(spi->master);
+
+	/*
+	 * Use SPI direct write mode if base address is available. Otherwise
+	 * fall back to PIO mode for this transfer.
+	 */
+	if ((orion_spi->direct_access[cs].vaddr) && (xfer->tx_buf) &&
+	    (word_len == 8)) {
+		/*
+		 * Send the TX-data to the SPI device via the direct
+		 * mapped address window
+		 */
+		writesl(orion_spi->direct_access[cs].vaddr, xfer->tx_buf,
+			DIV_ROUND_UP(count, 4));
+
+		return count;
+	}
+
 	if (word_len == 8) {
 		const u8 *tx = xfer->tx_buf;
 		u8 *rx = xfer->rx_buf;
@@ -425,6 +456,10 @@ static int orion_spi_reset(struct orion_spi *orion_spi)
 {
 	/* Verify that the CS is deasserted */
 	orion_spi_clrbits(orion_spi, ORION_SPI_IF_CTRL_REG, 0x1);
+
+	/* Don't deassert CS between the direct mapped SPI transfers */
+	writel(0, spi_reg(orion_spi, SPI_DIRECT_WRITE_CONFIG_REG));
+
 	return 0;
 }
 
@@ -504,6 +539,7 @@ static int orion_spi_probe(struct platform_device *pdev)
 	struct resource *r;
 	unsigned long tclk_hz;
 	int status = 0;
+	struct device_node *np;
 
 	master = spi_alloc_master(&pdev->dev, sizeof(*spi));
 	if (master == NULL) {
@@ -576,6 +612,49 @@ static int orion_spi_probe(struct platform_device *pdev)
 		goto out_rel_clk;
 	}
 
+	/* Scan all SPI devices of this controller for direct mapped devices */
+	for_each_available_child_of_node(pdev->dev.of_node, np) {
+		u32 cs;
+
+		/* Get chip-select number from the "reg" property */
+		status = of_property_read_u32(np, "reg", &cs);
+		if (status) {
+			dev_err(&pdev->dev,
+				"%s has no valid 'reg' property (%d)\n",
+				np->full_name, status);
+			status = 0;
+			continue;
+		}
+
+		/*
+		 * Check if an address is configured for this SPI device. If
+		 * not, the MBus mapping via the 'ranges' property in the 'soc'
+		 * node is not configured and this device should not use the
+		 * direct mode. In this case, just continue with the next
+		 * device.
+		 */
+		status = of_address_to_resource(pdev->dev.of_node, cs + 1, r);
+		if (status)
+			continue;
+
+		/*
+		 * Only map one page for direct access. This is enough for the
+		 * simple TX transfer which only writes to the first word.
+		 * This needs to get extended for the direct SPI-NOR / SPI-NAND
+		 * support, once this gets implemented.
+		 */
+		spi->direct_access[cs].vaddr = devm_ioremap(&pdev->dev,
+							    r->start,
+							    PAGE_SIZE);
+		if (IS_ERR(spi->direct_access[cs].vaddr)) {
+			status = PTR_ERR(spi->direct_access[cs].vaddr);
+			goto out_rel_clk;
+		}
+		spi->direct_access[cs].size = PAGE_SIZE;
+
+		dev_info(&pdev->dev, "CS%d configured for direct access\n", cs);
+	}
+
 	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

This patch adds support for the direct write mode to the Orion SPI
driver which is used on the Marvell Armada based SoCs. In this direct
mode, all data written to (or read from) a specifically mapped MBus
window (linked to one SPI chip-select on one of the SPI controllers)
will be transferred directly to the SPI bus. Without the need to control
the SPI registers in between. This can improve the SPI transfer rate in
such cases.

Currently only the direct write mode is supported. This mode especially
benefits from the SPI direct mode, as the data bytes are written
head-to-head to the SPI bus, without any additional addresses, that
are also written in the direct read mode.

One use-case for this direct write mode is, programming a FPGA bitstream
image into the FPGA connected to the SPI bus at maximum speed.

This mode is described in chapter "22.5.2 Direct Write to SPI" in the
Marvell Armada XP Functional Spec Datasheet.

It should be possible to support SPI-NOR and SPI-NAND devices via
this direct access mode as well. But this needs further work, e.g.:
- The mapping of the MBus window needs to get extended to span
  the complete flash device size
- The address / control data needs to get inserted into the SPI
  controller registers

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Brown <broonie@kernel.org>
---
v6:
- Switched from memcpy() to writesl() for the TX transfer.
- Only one page is mapped via ioremap as this is sufficient for
  the currently implemented simple TX transfer.
- Removed max_transfer_size() as its not needed with the current
  one page mapping that supports an unlimited amount of SPI data.
- Added a comment to the 'reg' description in the DT bindings
  documentation as suggested by Arnd.
- Changed 'reg' and 'ranges' to use '<' and '>' in this file.
- Changed size to 0xffffffff in this file.
- Added a small paragraph to the commit text, describing the
  possibility to support SPI-NOR & SPI-NAND devices via this
  direct access mode.

v5:
- Added some documentation for the direct mode to the orion-spi DT
  bindings document, including an example and a reference to the
  mbus DT bindings documentation.

v4:
- Add max_transfer_size()
- Fall back from direct-write mode to PIO mode when
  - transfer size is exceedeed
  - non-8bit transfers
- Restrict to direct-write mode for now. SPI direct read mode can
  be added later, when someone has a platform supporting this
  mode.

v3:
- Used static MBus windows again, as suggested by Arnd
- No new DT bindings needed for this. The MBus windows need to be
  configured in the 'reg' property of the SPI controller. This is
  done in a separate patch for the Armada platforms.
- The direct mapping is configured and enable by adding the
  specific MBus entry to the 'ranges' property of the 'soc' node
  in the board dts file.

v2:
- Use one MBus window for each SPI controller instead of one for
  for each SPI device. This MBus window is re-assigned, once the
  CS changes.
- Assert the CS over the entire message
- Don't restrict the direct access mode to only direct write mode
- Add check for max size before using memcpy()
- Remove spidev from DT bindings documentation

 .../devicetree/bindings/spi/spi-orion.txt          | 49 +++++++++++++-
 drivers/spi/spi-orion.c                            | 79 ++++++++++++++++++++++
 2 files changed, 127 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
index 98bc698..4f629cc 100644
--- a/Documentation/devicetree/bindings/spi/spi-orion.txt
+++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
@@ -8,7 +8,15 @@ Required properties:
     - "marvell,armada-380-spi", for the Armada 38x SoCs
     - "marvell,armada-390-spi", for the Armada 39x SoCs
     - "marvell,armada-xp-spi", for the Armada XP SoCs
-- reg : offset and length of the register set for the device
+- reg : offset and length of the register set for the device.
+	This property can optionally have additional entries to configure
+	the SPI direct access mode that some of the Marvell SoCs support
+	additionally to the normal indirect access (PIO) mode. The values
+	for the MBus "target" and "attribute" are defined in the Marvell
+	SoC "Functional Specifications" Manual in the chapter "Marvell
+	Core Processor Address Decoding".
+	The eight register sets following the control registers refer to
+	chip-select lines 0 through 7 respectively.
 - cell-index : Which of multiple SPI controllers is this.
 Optional properties:
 - interrupts : Is currently not used.
@@ -23,3 +31,42 @@ Example:
 	       interrupts = <23>;
 	       status = "disabled";
        };
+
+Example with SPI direct mode support (optionally):
+	spi0: spi at 10600 {
+		compatible = "marvell,orion-spi";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cell-index = <0>;
+		reg = <MBUS_ID(0xf0, 0x01) 0x10600 0x28>, /* control */
+		      <MBUS_ID(0x01, 0x1e) 0 0xffffffff>, /* CS0 */
+		      <MBUS_ID(0x01, 0x5e) 0 0xffffffff>, /* CS1 */
+		      <MBUS_ID(0x01, 0x9e) 0 0xffffffff>, /* CS2 */
+		      <MBUS_ID(0x01, 0xde) 0 0xffffffff>, /* CS3 */
+		      <MBUS_ID(0x01, 0x1f) 0 0xffffffff>, /* CS4 */
+		      <MBUS_ID(0x01, 0x5f) 0 0xffffffff>, /* CS5 */
+		      <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */
+		      <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */
+		interrupts = <23>;
+		status = "disabled";
+	};
+
+To enable the direct mode, the board specific 'ranges' property in the
+'soc' node needs to add the entries for the desired SPI controllers
+and its chip-selects that are used in the direct mode instead of PIO
+mode. Here an example for this (SPI controller 0, device 1 and SPI
+controller 1, device 2 are used in direct mode. All other SPI device
+are used in the default indirect (PIO) mode):
+	soc {
+		/*
+		 * Enable the SPI direct access by configuring an entry
+		 * here in the board-specific ranges property
+		 */
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000>,	/* internal regs */
+			 <MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>,	/* BootROM       */
+			 <MBUS_ID(0x01, 0x5e) 0 0 0xf1100000 0x10000>,	/* SPI0-DEV1 */
+			 <MBUS_ID(0x01, 0x9a) 0 0 0xf1110000 0x10000>;	/* SPI1-DEV2 */
+
+For further information on the MBus bindings, please see the MBus
+DT documentation:
+Documentation/devicetree/bindings/bus/mvebu-mbus.txt
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index a87cfd4..3e20afd 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -18,6 +18,7 @@
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/clk.h>
 #include <linux/sizes.h>
@@ -43,6 +44,9 @@
 #define ORION_SPI_INT_CAUSE_REG		0x10
 #define ORION_SPI_TIMING_PARAMS_REG	0x18
 
+/* Register for the "Direct Mode" */
+#define SPI_DIRECT_WRITE_CONFIG_REG	0x20
+
 #define ORION_SPI_TMISO_SAMPLE_MASK	(0x3 << 6)
 #define ORION_SPI_TMISO_SAMPLE_1	(1 << 6)
 #define ORION_SPI_TMISO_SAMPLE_2	(2 << 6)
@@ -78,11 +82,18 @@ struct orion_spi_dev {
 	bool			is_errata_50mhz_ac;
 };
 
+struct orion_direct_acc {
+	void __iomem		*vaddr;
+	u32			size;
+};
+
 struct orion_spi {
 	struct spi_master	*master;
 	void __iomem		*base;
 	struct clk              *clk;
 	const struct orion_spi_dev *devdata;
+
+	struct orion_direct_acc	direct_access[ORION_NUM_CHIPSELECTS];
 };
 
 static inline void __iomem *spi_reg(struct orion_spi *orion_spi, u32 reg)
@@ -372,10 +383,30 @@ orion_spi_write_read(struct spi_device *spi, struct spi_transfer *xfer)
 {
 	unsigned int count;
 	int word_len;
+	struct orion_spi *orion_spi;
+	int cs = spi->chip_select;
 
 	word_len = spi->bits_per_word;
 	count = xfer->len;
 
+	orion_spi = spi_master_get_devdata(spi->master);
+
+	/*
+	 * Use SPI direct write mode if base address is available. Otherwise
+	 * fall back to PIO mode for this transfer.
+	 */
+	if ((orion_spi->direct_access[cs].vaddr) && (xfer->tx_buf) &&
+	    (word_len == 8)) {
+		/*
+		 * Send the TX-data to the SPI device via the direct
+		 * mapped address window
+		 */
+		writesl(orion_spi->direct_access[cs].vaddr, xfer->tx_buf,
+			DIV_ROUND_UP(count, 4));
+
+		return count;
+	}
+
 	if (word_len == 8) {
 		const u8 *tx = xfer->tx_buf;
 		u8 *rx = xfer->rx_buf;
@@ -425,6 +456,10 @@ static int orion_spi_reset(struct orion_spi *orion_spi)
 {
 	/* Verify that the CS is deasserted */
 	orion_spi_clrbits(orion_spi, ORION_SPI_IF_CTRL_REG, 0x1);
+
+	/* Don't deassert CS between the direct mapped SPI transfers */
+	writel(0, spi_reg(orion_spi, SPI_DIRECT_WRITE_CONFIG_REG));
+
 	return 0;
 }
 
@@ -504,6 +539,7 @@ static int orion_spi_probe(struct platform_device *pdev)
 	struct resource *r;
 	unsigned long tclk_hz;
 	int status = 0;
+	struct device_node *np;
 
 	master = spi_alloc_master(&pdev->dev, sizeof(*spi));
 	if (master == NULL) {
@@ -576,6 +612,49 @@ static int orion_spi_probe(struct platform_device *pdev)
 		goto out_rel_clk;
 	}
 
+	/* Scan all SPI devices of this controller for direct mapped devices */
+	for_each_available_child_of_node(pdev->dev.of_node, np) {
+		u32 cs;
+
+		/* Get chip-select number from the "reg" property */
+		status = of_property_read_u32(np, "reg", &cs);
+		if (status) {
+			dev_err(&pdev->dev,
+				"%s has no valid 'reg' property (%d)\n",
+				np->full_name, status);
+			status = 0;
+			continue;
+		}
+
+		/*
+		 * Check if an address is configured for this SPI device. If
+		 * not, the MBus mapping via the 'ranges' property in the 'soc'
+		 * node is not configured and this device should not use the
+		 * direct mode. In this case, just continue with the next
+		 * device.
+		 */
+		status = of_address_to_resource(pdev->dev.of_node, cs + 1, r);
+		if (status)
+			continue;
+
+		/*
+		 * Only map one page for direct access. This is enough for the
+		 * simple TX transfer which only writes to the first word.
+		 * This needs to get extended for the direct SPI-NOR / SPI-NAND
+		 * support, once this gets implemented.
+		 */
+		spi->direct_access[cs].vaddr = devm_ioremap(&pdev->dev,
+							    r->start,
+							    PAGE_SIZE);
+		if (IS_ERR(spi->direct_access[cs].vaddr)) {
+			status = PTR_ERR(spi->direct_access[cs].vaddr);
+			goto out_rel_clk;
+		}
+		spi->direct_access[cs].size = PAGE_SIZE;
+
+		dev_info(&pdev->dev, "CS%d configured for direct access\n", cs);
+	}
+
 	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
-- 
2.8.1

Re: [PATCH v6] spi: orion.c: Add direct access mode

[Gregory CLEMENT]

Hi Stefan,
 
 On mer., avril 20 2016, Stefan Roese <sr-ynQEQJNshbs@public.gmane.org> wrote:

> This patch adds support for the direct write mode to the Orion SPI
> driver which is used on the Marvell Armada based SoCs. In this direct
> mode, all data written to (or read from) a specifically mapped MBus
> window (linked to one SPI chip-select on one of the SPI controllers)
> will be transferred directly to the SPI bus. Without the need to control
> the SPI registers in between. This can improve the SPI transfer rate in
> such cases.
>
> Currently only the direct write mode is supported. This mode especially
> benefits from the SPI direct mode, as the data bytes are written
> head-to-head to the SPI bus, without any additional addresses, that
> are also written in the direct read mode.
>
> One use-case for this direct write mode is, programming a FPGA bitstream
> image into the FPGA connected to the SPI bus at maximum speed.
>
> This mode is described in chapter "22.5.2 Direct Write to SPI" in the
> Marvell Armada XP Functional Spec Datasheet.
>
> It should be possible to support SPI-NOR and SPI-NAND devices via
> this direct access mode as well. But this needs further work, e.g.:
> - The mapping of the MBus window needs to get extended to span
>   the complete flash device size
> - The address / control data needs to get inserted into the SPI
>   controller registers

This patch looks really nice. And, from my point of view, especially
because I don't see how it could introduce a regression for the existing
boards :)

[...]

> diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
> index 98bc698..4f629cc 100644
> --- a/Documentation/devicetree/bindings/spi/spi-orion.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
> @@ -8,7 +8,15 @@ Required properties:
>      - "marvell,armada-380-spi", for the Armada 38x SoCs
>      - "marvell,armada-390-spi", for the Armada 39x SoCs
>      - "marvell,armada-xp-spi", for the Armada XP SoCs
> -- reg : offset and length of the register set for the device
> +- reg : offset and length of the register set for the device.
> +	This property can optionally have additional entries to configure
> +	the SPI direct access mode that some of the Marvell SoCs support
> +	additionally to the normal indirect access (PIO) mode. The values
> +	for the MBus "target" and "attribute" are defined in the Marvell
> +	SoC "Functional Specifications" Manual in the chapter "Marvell
> +	Core Processor Address Decoding".
> +	The eight register sets following the control registers refer to
> +	chip-select lines 0 through 7 respectively.
>  - cell-index : Which of multiple SPI controllers is this.
>  Optional properties:
>  - interrupts : Is currently not used.
> @@ -23,3 +31,42 @@ Example:
>  	       interrupts = <23>;
>  	       status = "disabled";
>         };
> +
> +Example with SPI direct mode support (optionally):
> +	spi0: spi@10600 {
> +		compatible = "marvell,orion-spi";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		cell-index = <0>;
> +		reg = <MBUS_ID(0xf0, 0x01) 0x10600 0x28>, /* control */
> +		      <MBUS_ID(0x01, 0x1e) 0 0xffffffff>, /* CS0 */
> +		      <MBUS_ID(0x01, 0x5e) 0 0xffffffff>, /* CS1 */
> +		      <MBUS_ID(0x01, 0x9e) 0 0xffffffff>, /* CS2 */
> +		      <MBUS_ID(0x01, 0xde) 0 0xffffffff>, /* CS3 */
> +		      <MBUS_ID(0x01, 0x1f) 0 0xffffffff>, /* CS4 */
> +		      <MBUS_ID(0x01, 0x5f) 0 0xffffffff>, /* CS5 */
> +		      <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */
> +		      <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */
> +		interrupts = <23>;
> +		status = "disabled";
> +	};
> +

As you don't submit any patch for the dtsi, I assume that you expect
that this part will be done at board level. In this case as I wrote
above we are sure that all the board continue working without any need
to test them.

[...]
> diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
> index a87cfd4..3e20afd 100644
> --- a/drivers/spi/spi-orion.c
> +++ b/drivers/spi/spi-orion.c
> @@ -18,6 +18,7 @@
>  #include <linux/module.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/of.h>
> +#include <linux/of_address.h>
>  #include <linux/of_device.h>
>  #include <linux/clk.h>
>  #include <linux/sizes.h>
> @@ -43,6 +44,9 @@
>  #define ORION_SPI_INT_CAUSE_REG		0x10
>  #define ORION_SPI_TIMING_PARAMS_REG	0x18
>  
> +/* Register for the "Direct Mode" */
> +#define SPI_DIRECT_WRITE_CONFIG_REG	0x20
> +
>  #define ORION_SPI_TMISO_SAMPLE_MASK	(0x3 << 6)
>  #define ORION_SPI_TMISO_SAMPLE_1	(1 << 6)
>  #define ORION_SPI_TMISO_SAMPLE_2	(2 << 6)
> @@ -78,11 +82,18 @@ struct orion_spi_dev {
>  	bool			is_errata_50mhz_ac;
>  };
>  
> +struct orion_direct_acc {
> +	void __iomem		*vaddr;
> +	u32			size;
> +};
> +
>  struct orion_spi {
>  	struct spi_master	*master;
>  	void __iomem		*base;
>  	struct clk              *clk;
>  	const struct orion_spi_dev *devdata;
> +
> +	struct orion_direct_acc	direct_access[ORION_NUM_CHIPSELECTS];
>  };
>  
>  static inline void __iomem *spi_reg(struct orion_spi *orion_spi, u32 reg)
> @@ -372,10 +383,30 @@ orion_spi_write_read(struct spi_device *spi, struct spi_transfer *xfer)
>  {
>  	unsigned int count;
>  	int word_len;
> +	struct orion_spi *orion_spi;
> +	int cs = spi->chip_select;
>  
>  	word_len = spi->bits_per_word;
>  	count = xfer->len;
>  
> +	orion_spi = spi_master_get_devdata(spi->master);
> +
> +	/*
> +	 * Use SPI direct write mode if base address is available. Otherwise
> +	 * fall back to PIO mode for this transfer.
> +	 */

That means that once the direct write mode is set in the device tree you
can't go back to the PIO mode. So, if I understand well, once you have
programmed a FPGA bitstream image into the FPGA you won't use this SPI
for a more standard communication. However, I don't know how to switch
from a mode to another in an elegant way (without adding an ioctl
command).

> +	if ((orion_spi->direct_access[cs].vaddr) && (xfer->tx_buf) &&
> +	    (word_len == 8)) {
> +		/*
> +		 * Send the TX-data to the SPI device via the direct
> +		 * mapped address window
> +		 */
> +		writesl(orion_spi->direct_access[cs].vaddr, xfer->tx_buf,
> +			DIV_ROUND_UP(count, 4));
> +
> +		return count;
> +	}
> +
>  	if (word_len == 8) {
>  		const u8 *tx = xfer->tx_buf;
>  		u8 *rx = xfer->rx_buf;

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] spi: orion.c: Add direct access mode

[Gregory CLEMENT]

Hi Stefan,
 
 On mer., avril 20 2016, Stefan Roese <sr@denx.de> wrote:

> This patch adds support for the direct write mode to the Orion SPI
> driver which is used on the Marvell Armada based SoCs. In this direct
> mode, all data written to (or read from) a specifically mapped MBus
> window (linked to one SPI chip-select on one of the SPI controllers)
> will be transferred directly to the SPI bus. Without the need to control
> the SPI registers in between. This can improve the SPI transfer rate in
> such cases.
>
> Currently only the direct write mode is supported. This mode especially
> benefits from the SPI direct mode, as the data bytes are written
> head-to-head to the SPI bus, without any additional addresses, that
> are also written in the direct read mode.
>
> One use-case for this direct write mode is, programming a FPGA bitstream
> image into the FPGA connected to the SPI bus at maximum speed.
>
> This mode is described in chapter "22.5.2 Direct Write to SPI" in the
> Marvell Armada XP Functional Spec Datasheet.
>
> It should be possible to support SPI-NOR and SPI-NAND devices via
> this direct access mode as well. But this needs further work, e.g.:
> - The mapping of the MBus window needs to get extended to span
>   the complete flash device size
> - The address / control data needs to get inserted into the SPI
>   controller registers

This patch looks really nice. And, from my point of view, especially
because I don't see how it could introduce a regression for the existing
boards :)

[...]

> diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
> index 98bc698..4f629cc 100644
> --- a/Documentation/devicetree/bindings/spi/spi-orion.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
> @@ -8,7 +8,15 @@ Required properties:
>      - "marvell,armada-380-spi", for the Armada 38x SoCs
>      - "marvell,armada-390-spi", for the Armada 39x SoCs
>      - "marvell,armada-xp-spi", for the Armada XP SoCs
> -- reg : offset and length of the register set for the device
> +- reg : offset and length of the register set for the device.
> +	This property can optionally have additional entries to configure
> +	the SPI direct access mode that some of the Marvell SoCs support
> +	additionally to the normal indirect access (PIO) mode. The values
> +	for the MBus "target" and "attribute" are defined in the Marvell
> +	SoC "Functional Specifications" Manual in the chapter "Marvell
> +	Core Processor Address Decoding".
> +	The eight register sets following the control registers refer to
> +	chip-select lines 0 through 7 respectively.
>  - cell-index : Which of multiple SPI controllers is this.
>  Optional properties:
>  - interrupts : Is currently not used.
> @@ -23,3 +31,42 @@ Example:
>  	       interrupts = <23>;
>  	       status = "disabled";
>         };
> +
> +Example with SPI direct mode support (optionally):
> +	spi0: spi at 10600 {
> +		compatible = "marvell,orion-spi";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		cell-index = <0>;
> +		reg = <MBUS_ID(0xf0, 0x01) 0x10600 0x28>, /* control */
> +		      <MBUS_ID(0x01, 0x1e) 0 0xffffffff>, /* CS0 */
> +		      <MBUS_ID(0x01, 0x5e) 0 0xffffffff>, /* CS1 */
> +		      <MBUS_ID(0x01, 0x9e) 0 0xffffffff>, /* CS2 */
> +		      <MBUS_ID(0x01, 0xde) 0 0xffffffff>, /* CS3 */
> +		      <MBUS_ID(0x01, 0x1f) 0 0xffffffff>, /* CS4 */
> +		      <MBUS_ID(0x01, 0x5f) 0 0xffffffff>, /* CS5 */
> +		      <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */
> +		      <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */
> +		interrupts = <23>;
> +		status = "disabled";
> +	};
> +

As you don't submit any patch for the dtsi, I assume that you expect
that this part will be done at board level. In this case as I wrote
above we are sure that all the board continue working without any need
to test them.

[...]
> diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
> index a87cfd4..3e20afd 100644
> --- a/drivers/spi/spi-orion.c
> +++ b/drivers/spi/spi-orion.c
> @@ -18,6 +18,7 @@
>  #include <linux/module.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/of.h>
> +#include <linux/of_address.h>
>  #include <linux/of_device.h>
>  #include <linux/clk.h>
>  #include <linux/sizes.h>
> @@ -43,6 +44,9 @@
>  #define ORION_SPI_INT_CAUSE_REG		0x10
>  #define ORION_SPI_TIMING_PARAMS_REG	0x18
>  
> +/* Register for the "Direct Mode" */
> +#define SPI_DIRECT_WRITE_CONFIG_REG	0x20
> +
>  #define ORION_SPI_TMISO_SAMPLE_MASK	(0x3 << 6)
>  #define ORION_SPI_TMISO_SAMPLE_1	(1 << 6)
>  #define ORION_SPI_TMISO_SAMPLE_2	(2 << 6)
> @@ -78,11 +82,18 @@ struct orion_spi_dev {
>  	bool			is_errata_50mhz_ac;
>  };
>  
> +struct orion_direct_acc {
> +	void __iomem		*vaddr;
> +	u32			size;
> +};
> +
>  struct orion_spi {
>  	struct spi_master	*master;
>  	void __iomem		*base;
>  	struct clk              *clk;
>  	const struct orion_spi_dev *devdata;
> +
> +	struct orion_direct_acc	direct_access[ORION_NUM_CHIPSELECTS];
>  };
>  
>  static inline void __iomem *spi_reg(struct orion_spi *orion_spi, u32 reg)
> @@ -372,10 +383,30 @@ orion_spi_write_read(struct spi_device *spi, struct spi_transfer *xfer)
>  {
>  	unsigned int count;
>  	int word_len;
> +	struct orion_spi *orion_spi;
> +	int cs = spi->chip_select;
>  
>  	word_len = spi->bits_per_word;
>  	count = xfer->len;
>  
> +	orion_spi = spi_master_get_devdata(spi->master);
> +
> +	/*
> +	 * Use SPI direct write mode if base address is available. Otherwise
> +	 * fall back to PIO mode for this transfer.
> +	 */

That means that once the direct write mode is set in the device tree you
can't go back to the PIO mode. So, if I understand well, once you have
programmed a FPGA bitstream image into the FPGA you won't use this SPI
for a more standard communication. However, I don't know how to switch
from a mode to another in an elegant way (without adding an ioctl
command).

> +	if ((orion_spi->direct_access[cs].vaddr) && (xfer->tx_buf) &&
> +	    (word_len == 8)) {
> +		/*
> +		 * Send the TX-data to the SPI device via the direct
> +		 * mapped address window
> +		 */
> +		writesl(orion_spi->direct_access[cs].vaddr, xfer->tx_buf,
> +			DIV_ROUND_UP(count, 4));
> +
> +		return count;
> +	}
> +
>  	if (word_len == 8) {
>  		const u8 *tx = xfer->tx_buf;
>  		u8 *rx = xfer->rx_buf;

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

Hi Gregory,

On 20.04.2016 13:58, Gregory CLEMENT wrote:
>   On mer., avril 20 2016, Stefan Roese <sr-ynQEQJNshbs@public.gmane.org> wrote:
> 
>> This patch adds support for the direct write mode to the Orion SPI
>> driver which is used on the Marvell Armada based SoCs. In this direct
>> mode, all data written to (or read from) a specifically mapped MBus
>> window (linked to one SPI chip-select on one of the SPI controllers)
>> will be transferred directly to the SPI bus. Without the need to control
>> the SPI registers in between. This can improve the SPI transfer rate in
>> such cases.
>>
>> Currently only the direct write mode is supported. This mode especially
>> benefits from the SPI direct mode, as the data bytes are written
>> head-to-head to the SPI bus, without any additional addresses, that
>> are also written in the direct read mode.
>>
>> One use-case for this direct write mode is, programming a FPGA bitstream
>> image into the FPGA connected to the SPI bus at maximum speed.
>>
>> This mode is described in chapter "22.5.2 Direct Write to SPI" in the
>> Marvell Armada XP Functional Spec Datasheet.
>>
>> It should be possible to support SPI-NOR and SPI-NAND devices via
>> this direct access mode as well. But this needs further work, e.g.:
>> - The mapping of the MBus window needs to get extended to span
>>    the complete flash device size
>> - The address / control data needs to get inserted into the SPI
>>    controller registers
> 
> This patch looks really nice. And, from my point of view, especially
> because I don't see how it could introduce a regression for the existing
> boards :)
> 
> [...]
> 
>> diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
>> index 98bc698..4f629cc 100644
>> --- a/Documentation/devicetree/bindings/spi/spi-orion.txt
>> +++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
>> @@ -8,7 +8,15 @@ Required properties:
>>       - "marvell,armada-380-spi", for the Armada 38x SoCs
>>       - "marvell,armada-390-spi", for the Armada 39x SoCs
>>       - "marvell,armada-xp-spi", for the Armada XP SoCs
>> -- reg : offset and length of the register set for the device
>> +- reg : offset and length of the register set for the device.
>> +	This property can optionally have additional entries to configure
>> +	the SPI direct access mode that some of the Marvell SoCs support
>> +	additionally to the normal indirect access (PIO) mode. The values
>> +	for the MBus "target" and "attribute" are defined in the Marvell
>> +	SoC "Functional Specifications" Manual in the chapter "Marvell
>> +	Core Processor Address Decoding".
>> +	The eight register sets following the control registers refer to
>> +	chip-select lines 0 through 7 respectively.
>>   - cell-index : Which of multiple SPI controllers is this.
>>   Optional properties:
>>   - interrupts : Is currently not used.
>> @@ -23,3 +31,42 @@ Example:
>>   	       interrupts = <23>;
>>   	       status = "disabled";
>>          };
>> +
>> +Example with SPI direct mode support (optionally):
>> +	spi0: spi@10600 {
>> +		compatible = "marvell,orion-spi";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		cell-index = <0>;
>> +		reg = <MBUS_ID(0xf0, 0x01) 0x10600 0x28>, /* control */
>> +		      <MBUS_ID(0x01, 0x1e) 0 0xffffffff>, /* CS0 */
>> +		      <MBUS_ID(0x01, 0x5e) 0 0xffffffff>, /* CS1 */
>> +		      <MBUS_ID(0x01, 0x9e) 0 0xffffffff>, /* CS2 */
>> +		      <MBUS_ID(0x01, 0xde) 0 0xffffffff>, /* CS3 */
>> +		      <MBUS_ID(0x01, 0x1f) 0 0xffffffff>, /* CS4 */
>> +		      <MBUS_ID(0x01, 0x5f) 0 0xffffffff>, /* CS5 */
>> +		      <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */
>> +		      <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */
>> +		interrupts = <23>;
>> +		status = "disabled";
>> +	};
>> +
> 
> As you don't submit any patch for the dtsi, I assume that you expect
> that this part will be done at board level. In this case as I wrote
> above we are sure that all the board continue working without any need
> to test them.

No, this won't work without any changes to the Armada dtsi /
dts files. As the SPI controller node needs to get moved
for this 'reg' property to work (suggestion from Arnd).

I've submitted 2 patches for the dtsi / dts files a short while
ago:

http://www.spinics.net/lists/arm-kernel/msg495524.html
http://www.spinics.net/lists/arm-kernel/msg495523.html

When this SPI driver patch gets accepted, I'll send an updated
patchset for the dtsi / dts files.
 
> [...]
>> diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
>> index a87cfd4..3e20afd 100644
>> --- a/drivers/spi/spi-orion.c
>> +++ b/drivers/spi/spi-orion.c
>> @@ -18,6 +18,7 @@
>>   #include <linux/module.h>
>>   #include <linux/pm_runtime.h>
>>   #include <linux/of.h>
>> +#include <linux/of_address.h>
>>   #include <linux/of_device.h>
>>   #include <linux/clk.h>
>>   #include <linux/sizes.h>
>> @@ -43,6 +44,9 @@
>>   #define ORION_SPI_INT_CAUSE_REG		0x10
>>   #define ORION_SPI_TIMING_PARAMS_REG	0x18
>>   
>> +/* Register for the "Direct Mode" */
>> +#define SPI_DIRECT_WRITE_CONFIG_REG	0x20
>> +
>>   #define ORION_SPI_TMISO_SAMPLE_MASK	(0x3 << 6)
>>   #define ORION_SPI_TMISO_SAMPLE_1	(1 << 6)
>>   #define ORION_SPI_TMISO_SAMPLE_2	(2 << 6)
>> @@ -78,11 +82,18 @@ struct orion_spi_dev {
>>   	bool			is_errata_50mhz_ac;
>>   };
>>   
>> +struct orion_direct_acc {
>> +	void __iomem		*vaddr;
>> +	u32			size;
>> +};
>> +
>>   struct orion_spi {
>>   	struct spi_master	*master;
>>   	void __iomem		*base;
>>   	struct clk              *clk;
>>   	const struct orion_spi_dev *devdata;
>> +
>> +	struct orion_direct_acc	direct_access[ORION_NUM_CHIPSELECTS];
>>   };
>>   
>>   static inline void __iomem *spi_reg(struct orion_spi *orion_spi, u32 reg)
>> @@ -372,10 +383,30 @@ orion_spi_write_read(struct spi_device *spi, struct spi_transfer *xfer)
>>   {
>>   	unsigned int count;
>>   	int word_len;
>> +	struct orion_spi *orion_spi;
>> +	int cs = spi->chip_select;
>>   
>>   	word_len = spi->bits_per_word;
>>   	count = xfer->len;
>>   
>> +	orion_spi = spi_master_get_devdata(spi->master);
>> +
>> +	/*
>> +	 * Use SPI direct write mode if base address is available. Otherwise
>> +	 * fall back to PIO mode for this transfer.
>> +	 */
> 
> That means that once the direct write mode is set in the device tree you
> can't go back to the PIO mode. So, if I understand well, once you have
> programmed a FPGA bitstream image into the FPGA you won't use this SPI
> for a more standard communication.

Correct. We're using this SPI bus on this "SPI device" for FPGA
programming only. This can be done multiple times though. Currently
there is no way to switch operation modes at runtime. I'm not sure
if this is really needed. Either a device supports this mode or
it doesn't. 

> However, I don't know how to switch
> from a mode to another in an elegant way (without adding an ioctl
> command).

Yes. Please see above, as I don't know if this is really needed
in practice.

Thanks,
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

Hi Gregory,

On 20.04.2016 13:58, Gregory CLEMENT wrote:
>   On mer., avril 20 2016, Stefan Roese <sr@denx.de> wrote:
> 
>> This patch adds support for the direct write mode to the Orion SPI
>> driver which is used on the Marvell Armada based SoCs. In this direct
>> mode, all data written to (or read from) a specifically mapped MBus
>> window (linked to one SPI chip-select on one of the SPI controllers)
>> will be transferred directly to the SPI bus. Without the need to control
>> the SPI registers in between. This can improve the SPI transfer rate in
>> such cases.
>>
>> Currently only the direct write mode is supported. This mode especially
>> benefits from the SPI direct mode, as the data bytes are written
>> head-to-head to the SPI bus, without any additional addresses, that
>> are also written in the direct read mode.
>>
>> One use-case for this direct write mode is, programming a FPGA bitstream
>> image into the FPGA connected to the SPI bus at maximum speed.
>>
>> This mode is described in chapter "22.5.2 Direct Write to SPI" in the
>> Marvell Armada XP Functional Spec Datasheet.
>>
>> It should be possible to support SPI-NOR and SPI-NAND devices via
>> this direct access mode as well. But this needs further work, e.g.:
>> - The mapping of the MBus window needs to get extended to span
>>    the complete flash device size
>> - The address / control data needs to get inserted into the SPI
>>    controller registers
> 
> This patch looks really nice. And, from my point of view, especially
> because I don't see how it could introduce a regression for the existing
> boards :)
> 
> [...]
> 
>> diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
>> index 98bc698..4f629cc 100644
>> --- a/Documentation/devicetree/bindings/spi/spi-orion.txt
>> +++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
>> @@ -8,7 +8,15 @@ Required properties:
>>       - "marvell,armada-380-spi", for the Armada 38x SoCs
>>       - "marvell,armada-390-spi", for the Armada 39x SoCs
>>       - "marvell,armada-xp-spi", for the Armada XP SoCs
>> -- reg : offset and length of the register set for the device
>> +- reg : offset and length of the register set for the device.
>> +	This property can optionally have additional entries to configure
>> +	the SPI direct access mode that some of the Marvell SoCs support
>> +	additionally to the normal indirect access (PIO) mode. The values
>> +	for the MBus "target" and "attribute" are defined in the Marvell
>> +	SoC "Functional Specifications" Manual in the chapter "Marvell
>> +	Core Processor Address Decoding".
>> +	The eight register sets following the control registers refer to
>> +	chip-select lines 0 through 7 respectively.
>>   - cell-index : Which of multiple SPI controllers is this.
>>   Optional properties:
>>   - interrupts : Is currently not used.
>> @@ -23,3 +31,42 @@ Example:
>>   	       interrupts = <23>;
>>   	       status = "disabled";
>>          };
>> +
>> +Example with SPI direct mode support (optionally):
>> +	spi0: spi at 10600 {
>> +		compatible = "marvell,orion-spi";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		cell-index = <0>;
>> +		reg = <MBUS_ID(0xf0, 0x01) 0x10600 0x28>, /* control */
>> +		      <MBUS_ID(0x01, 0x1e) 0 0xffffffff>, /* CS0 */
>> +		      <MBUS_ID(0x01, 0x5e) 0 0xffffffff>, /* CS1 */
>> +		      <MBUS_ID(0x01, 0x9e) 0 0xffffffff>, /* CS2 */
>> +		      <MBUS_ID(0x01, 0xde) 0 0xffffffff>, /* CS3 */
>> +		      <MBUS_ID(0x01, 0x1f) 0 0xffffffff>, /* CS4 */
>> +		      <MBUS_ID(0x01, 0x5f) 0 0xffffffff>, /* CS5 */
>> +		      <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */
>> +		      <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */
>> +		interrupts = <23>;
>> +		status = "disabled";
>> +	};
>> +
> 
> As you don't submit any patch for the dtsi, I assume that you expect
> that this part will be done at board level. In this case as I wrote
> above we are sure that all the board continue working without any need
> to test them.

No, this won't work without any changes to the Armada dtsi /
dts files. As the SPI controller node needs to get moved
for this 'reg' property to work (suggestion from Arnd).

I've submitted 2 patches for the dtsi / dts files a short while
ago:

http://www.spinics.net/lists/arm-kernel/msg495524.html
http://www.spinics.net/lists/arm-kernel/msg495523.html

When this SPI driver patch gets accepted, I'll send an updated
patchset for the dtsi / dts files.
 
> [...]
>> diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
>> index a87cfd4..3e20afd 100644
>> --- a/drivers/spi/spi-orion.c
>> +++ b/drivers/spi/spi-orion.c
>> @@ -18,6 +18,7 @@
>>   #include <linux/module.h>
>>   #include <linux/pm_runtime.h>
>>   #include <linux/of.h>
>> +#include <linux/of_address.h>
>>   #include <linux/of_device.h>
>>   #include <linux/clk.h>
>>   #include <linux/sizes.h>
>> @@ -43,6 +44,9 @@
>>   #define ORION_SPI_INT_CAUSE_REG		0x10
>>   #define ORION_SPI_TIMING_PARAMS_REG	0x18
>>   
>> +/* Register for the "Direct Mode" */
>> +#define SPI_DIRECT_WRITE_CONFIG_REG	0x20
>> +
>>   #define ORION_SPI_TMISO_SAMPLE_MASK	(0x3 << 6)
>>   #define ORION_SPI_TMISO_SAMPLE_1	(1 << 6)
>>   #define ORION_SPI_TMISO_SAMPLE_2	(2 << 6)
>> @@ -78,11 +82,18 @@ struct orion_spi_dev {
>>   	bool			is_errata_50mhz_ac;
>>   };
>>   
>> +struct orion_direct_acc {
>> +	void __iomem		*vaddr;
>> +	u32			size;
>> +};
>> +
>>   struct orion_spi {
>>   	struct spi_master	*master;
>>   	void __iomem		*base;
>>   	struct clk              *clk;
>>   	const struct orion_spi_dev *devdata;
>> +
>> +	struct orion_direct_acc	direct_access[ORION_NUM_CHIPSELECTS];
>>   };
>>   
>>   static inline void __iomem *spi_reg(struct orion_spi *orion_spi, u32 reg)
>> @@ -372,10 +383,30 @@ orion_spi_write_read(struct spi_device *spi, struct spi_transfer *xfer)
>>   {
>>   	unsigned int count;
>>   	int word_len;
>> +	struct orion_spi *orion_spi;
>> +	int cs = spi->chip_select;
>>   
>>   	word_len = spi->bits_per_word;
>>   	count = xfer->len;
>>   
>> +	orion_spi = spi_master_get_devdata(spi->master);
>> +
>> +	/*
>> +	 * Use SPI direct write mode if base address is available. Otherwise
>> +	 * fall back to PIO mode for this transfer.
>> +	 */
> 
> That means that once the direct write mode is set in the device tree you
> can't go back to the PIO mode. So, if I understand well, once you have
> programmed a FPGA bitstream image into the FPGA you won't use this SPI
> for a more standard communication.

Correct. We're using this SPI bus on this "SPI device" for FPGA
programming only. This can be done multiple times though. Currently
there is no way to switch operation modes at runtime. I'm not sure
if this is really needed. Either a device supports this mode or
it doesn't. 

> However, I don't know how to switch
> from a mode to another in an elegant way (without adding an ioctl
> command).

Yes. Please see above, as I don't know if this is really needed
in practice.

Thanks,
Stefan

Re: [PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

On 20.04.2016 12:11, Stefan Roese wrote:
> This patch adds support for the direct write mode to the Orion SPI
> driver which is used on the Marvell Armada based SoCs. In this direct
> mode, all data written to (or read from) a specifically mapped MBus
> window (linked to one SPI chip-select on one of the SPI controllers)
> will be transferred directly to the SPI bus. Without the need to control
> the SPI registers in between. This can improve the SPI transfer rate in
> such cases.
> 
> Currently only the direct write mode is supported. This mode especially
> benefits from the SPI direct mode, as the data bytes are written
> head-to-head to the SPI bus, without any additional addresses, that
> are also written in the direct read mode.
> 
> One use-case for this direct write mode is, programming a FPGA bitstream
> image into the FPGA connected to the SPI bus at maximum speed.
> 
> This mode is described in chapter "22.5.2 Direct Write to SPI" in the
> Marvell Armada XP Functional Spec Datasheet.
> 
> It should be possible to support SPI-NOR and SPI-NAND devices via
> this direct access mode as well. But this needs further work, e.g.:
> - The mapping of the MBus window needs to get extended to span
>    the complete flash device size
> - The address / control data needs to get inserted into the SPI
>    controller registers
> 
> Signed-off-by: Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>
> Cc: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Its been a while since v6 of this direct write access mode has been
posted. This is a gentle ping on its status.

Arnd / Mark, do you have any additional change requests or are you okay
with the current version?

Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

On 20.04.2016 12:11, Stefan Roese wrote:
> This patch adds support for the direct write mode to the Orion SPI
> driver which is used on the Marvell Armada based SoCs. In this direct
> mode, all data written to (or read from) a specifically mapped MBus
> window (linked to one SPI chip-select on one of the SPI controllers)
> will be transferred directly to the SPI bus. Without the need to control
> the SPI registers in between. This can improve the SPI transfer rate in
> such cases.
> 
> Currently only the direct write mode is supported. This mode especially
> benefits from the SPI direct mode, as the data bytes are written
> head-to-head to the SPI bus, without any additional addresses, that
> are also written in the direct read mode.
> 
> One use-case for this direct write mode is, programming a FPGA bitstream
> image into the FPGA connected to the SPI bus at maximum speed.
> 
> This mode is described in chapter "22.5.2 Direct Write to SPI" in the
> Marvell Armada XP Functional Spec Datasheet.
> 
> It should be possible to support SPI-NOR and SPI-NAND devices via
> this direct access mode as well. But this needs further work, e.g.:
> - The mapping of the MBus window needs to get extended to span
>    the complete flash device size
> - The address / control data needs to get inserted into the SPI
>    controller registers
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Mark Brown <broonie@kernel.org>

Its been a while since v6 of this direct write access mode has been
posted. This is a gentle ping on its status.

Arnd / Mark, do you have any additional change requests or are you okay
with the current version?

Thanks,
Stefan

Re: [PATCH v6] spi: orion.c: Add direct access mode

[Arnd Bergmann]

On Monday 02 May 2016 08:47:15 Stefan Roese wrote:
> On 20.04.2016 12:11, Stefan Roese wrote:
> > This patch adds support for the direct write mode to the Orion SPI
> > driver which is used on the Marvell Armada based SoCs. In this direct
> > mode, all data written to (or read from) a specifically mapped MBus
> > window (linked to one SPI chip-select on one of the SPI controllers)
> > will be transferred directly to the SPI bus. Without the need to control
> > the SPI registers in between. This can improve the SPI transfer rate in
> > such cases.
> > 
> > Currently only the direct write mode is supported. This mode especially
> > benefits from the SPI direct mode, as the data bytes are written
> > head-to-head to the SPI bus, without any additional addresses, that
> > are also written in the direct read mode.
> > 
> > One use-case for this direct write mode is, programming a FPGA bitstream
> > image into the FPGA connected to the SPI bus at maximum speed.
> > 
> > This mode is described in chapter "22.5.2 Direct Write to SPI" in the
> > Marvell Armada XP Functional Spec Datasheet.
> > 
> > It should be possible to support SPI-NOR and SPI-NAND devices via
> > this direct access mode as well. But this needs further work, e.g.:
> > - The mapping of the MBus window needs to get extended to span
> >    the complete flash device size
> > - The address / control data needs to get inserted into the SPI
> >    controller registers
> > 
> > Signed-off-by: Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>
> > Cc: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Cc: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> > Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> > Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> 
> Its been a while since v6 of this direct write access mode has been
> posted. This is a gentle ping on its status.
> 
> Arnd / Mark, do you have any additional change requests or are you okay
> with the current version?

No objections, please add

Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>

Two questions though:

- you now always send a multiple of four byte in each transfer, are
  there any downsides in doing this, e.g. some SPI devices that might
  get confused by receiving additional uninitialized data?

- How does the performance compare to the normal mode, is it basically
  unchanged, or does this patch make things faster?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] spi: orion.c: Add direct access mode

[Arnd Bergmann]

On Monday 02 May 2016 08:47:15 Stefan Roese wrote:
> On 20.04.2016 12:11, Stefan Roese wrote:
> > This patch adds support for the direct write mode to the Orion SPI
> > driver which is used on the Marvell Armada based SoCs. In this direct
> > mode, all data written to (or read from) a specifically mapped MBus
> > window (linked to one SPI chip-select on one of the SPI controllers)
> > will be transferred directly to the SPI bus. Without the need to control
> > the SPI registers in between. This can improve the SPI transfer rate in
> > such cases.
> > 
> > Currently only the direct write mode is supported. This mode especially
> > benefits from the SPI direct mode, as the data bytes are written
> > head-to-head to the SPI bus, without any additional addresses, that
> > are also written in the direct read mode.
> > 
> > One use-case for this direct write mode is, programming a FPGA bitstream
> > image into the FPGA connected to the SPI bus at maximum speed.
> > 
> > This mode is described in chapter "22.5.2 Direct Write to SPI" in the
> > Marvell Armada XP Functional Spec Datasheet.
> > 
> > It should be possible to support SPI-NOR and SPI-NAND devices via
> > this direct access mode as well. But this needs further work, e.g.:
> > - The mapping of the MBus window needs to get extended to span
> >    the complete flash device size
> > - The address / control data needs to get inserted into the SPI
> >    controller registers
> > 
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Mark Brown <broonie@kernel.org>
> 
> Its been a while since v6 of this direct write access mode has been
> posted. This is a gentle ping on its status.
> 
> Arnd / Mark, do you have any additional change requests or are you okay
> with the current version?

No objections, please add

Acked-by: Arnd Bergmann <arnd@arndb.de>

Two questions though:

- you now always send a multiple of four byte in each transfer, are
  there any downsides in doing this, e.g. some SPI devices that might
  get confused by receiving additional uninitialized data?

- How does the performance compare to the normal mode, is it basically
  unchanged, or does this patch make things faster?

	Arnd

Re: [PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

Hi Arnd,

On 02.05.2016 09:28, Arnd Bergmann wrote:
> On Monday 02 May 2016 08:47:15 Stefan Roese wrote:
>> On 20.04.2016 12:11, Stefan Roese wrote:
>>> This patch adds support for the direct write mode to the Orion SPI
>>> driver which is used on the Marvell Armada based SoCs. In this direct
>>> mode, all data written to (or read from) a specifically mapped MBus
>>> window (linked to one SPI chip-select on one of the SPI controllers)
>>> will be transferred directly to the SPI bus. Without the need to control
>>> the SPI registers in between. This can improve the SPI transfer rate in
>>> such cases.
>>>
>>> Currently only the direct write mode is supported. This mode especially
>>> benefits from the SPI direct mode, as the data bytes are written
>>> head-to-head to the SPI bus, without any additional addresses, that
>>> are also written in the direct read mode.
>>>
>>> One use-case for this direct write mode is, programming a FPGA bitstream
>>> image into the FPGA connected to the SPI bus at maximum speed.
>>>
>>> This mode is described in chapter "22.5.2 Direct Write to SPI" in the
>>> Marvell Armada XP Functional Spec Datasheet.
>>>
>>> It should be possible to support SPI-NOR and SPI-NAND devices via
>>> this direct access mode as well. But this needs further work, e.g.:
>>> - The mapping of the MBus window needs to get extended to span
>>>     the complete flash device size
>>> - The address / control data needs to get inserted into the SPI
>>>     controller registers
>>>
>>> Signed-off-by: Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>
>>> Cc: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>> Cc: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>> Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>>> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>>> Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> Its been a while since v6 of this direct write access mode has been
>> posted. This is a gentle ping on its status.
>>
>> Arnd / Mark, do you have any additional change requests or are you okay
>> with the current version?
> 
> No objections, please add
> 
> Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>

Thanks.
 
> Two questions though:
> 
> - you now always send a multiple of four byte in each transfer, are
>    there any downsides in doing this, e.g. some SPI devices that might
>    get confused by receiving additional uninitialized data?

Yes, this is something that might happen on such devices. AFAIK, my
device (Altera FPGA) has no such restriction though. IIRC, the
size of the bitfiles is always 4-byte aligned.

I'll try to send v7 of this patch with a fully byte-size correct 
handling later today.
 
> - How does the performance compare to the normal mode, is it basically
>    unchanged, or does this patch make things faster?

The performance is increased. The factor of course depends on the SPI
transfer speed. Here the numbers for a ~70KiB image transferred at
27MHz SPI speed:

Using the PIO SPI transfer:

real    0m0.128s
user    0m0.010s
sys     0m0.120s

Using the direct write mode:

real    0m0.040s
user    0m0.000s
sys     0m0.020s

Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

Hi Arnd,

On 02.05.2016 09:28, Arnd Bergmann wrote:
> On Monday 02 May 2016 08:47:15 Stefan Roese wrote:
>> On 20.04.2016 12:11, Stefan Roese wrote:
>>> This patch adds support for the direct write mode to the Orion SPI
>>> driver which is used on the Marvell Armada based SoCs. In this direct
>>> mode, all data written to (or read from) a specifically mapped MBus
>>> window (linked to one SPI chip-select on one of the SPI controllers)
>>> will be transferred directly to the SPI bus. Without the need to control
>>> the SPI registers in between. This can improve the SPI transfer rate in
>>> such cases.
>>>
>>> Currently only the direct write mode is supported. This mode especially
>>> benefits from the SPI direct mode, as the data bytes are written
>>> head-to-head to the SPI bus, without any additional addresses, that
>>> are also written in the direct read mode.
>>>
>>> One use-case for this direct write mode is, programming a FPGA bitstream
>>> image into the FPGA connected to the SPI bus at maximum speed.
>>>
>>> This mode is described in chapter "22.5.2 Direct Write to SPI" in the
>>> Marvell Armada XP Functional Spec Datasheet.
>>>
>>> It should be possible to support SPI-NOR and SPI-NAND devices via
>>> this direct access mode as well. But this needs further work, e.g.:
>>> - The mapping of the MBus window needs to get extended to span
>>>     the complete flash device size
>>> - The address / control data needs to get inserted into the SPI
>>>     controller registers
>>>
>>> Signed-off-by: Stefan Roese <sr@denx.de>
>>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>> Cc: Andrew Lunn <andrew@lunn.ch>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Mark Brown <broonie@kernel.org>
>>
>> Its been a while since v6 of this direct write access mode has been
>> posted. This is a gentle ping on its status.
>>
>> Arnd / Mark, do you have any additional change requests or are you okay
>> with the current version?
> 
> No objections, please add
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Thanks.
 
> Two questions though:
> 
> - you now always send a multiple of four byte in each transfer, are
>    there any downsides in doing this, e.g. some SPI devices that might
>    get confused by receiving additional uninitialized data?

Yes, this is something that might happen on such devices. AFAIK, my
device (Altera FPGA) has no such restriction though. IIRC, the
size of the bitfiles is always 4-byte aligned.

I'll try to send v7 of this patch with a fully byte-size correct 
handling later today.
 
> - How does the performance compare to the normal mode, is it basically
>    unchanged, or does this patch make things faster?

The performance is increased. The factor of course depends on the SPI
transfer speed. Here the numbers for a ~70KiB image transferred at
27MHz SPI speed:

Using the PIO SPI transfer:

real    0m0.128s
user    0m0.010s
sys     0m0.120s

Using the direct write mode:

real    0m0.040s
user    0m0.000s
sys     0m0.020s

Thanks,
Stefan

Re: [PATCH v6] spi: orion.c: Add direct access mode

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

On Mon, May 02, 2016 at 09:28:34AM +0200, Arnd Bergmann wrote:
> On Monday 02 May 2016 08:47:15 Stefan Roese wrote:

> > Its been a while since v6 of this direct write access mode has been
> > posted. This is a gentle ping on its status.

> > Arnd / Mark, do you have any additional change requests or are you okay
> > with the current version?

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings just adds to the mail volume (if they are
seen at all) and if something has gone wrong you'll have to resend the
patches anyway.

> - you now always send a multiple of four byte in each transfer, are
>   there any downsides in doing this, e.g. some SPI devices that might
>   get confused by receiving additional uninitialized data?

Yes, this will break a large proportion of devices.

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

[PATCH v6] spi: orion.c: Add direct access mode

[Mark Brown]

On Mon, May 02, 2016 at 09:28:34AM +0200, Arnd Bergmann wrote:
> On Monday 02 May 2016 08:47:15 Stefan Roese wrote:

> > Its been a while since v6 of this direct write access mode has been
> > posted. This is a gentle ping on its status.

> > Arnd / Mark, do you have any additional change requests or are you okay
> > with the current version?

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings just adds to the mail volume (if they are
seen at all) and if something has gone wrong you'll have to resend the
patches anyway.

> - you now always send a multiple of four byte in each transfer, are
>   there any downsides in doing this, e.g. some SPI devices that might
>   get confused by receiving additional uninitialized data?

Yes, this will break a large proportion of devices.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160502/b84af846/attachment.sig>

Re: [PATCH v6] spi: orion.c: Add direct access mode

[Gregory CLEMENT]

Hi Stefan,
 
 On mer., avril 20 2016, Stefan Roese <sr-ynQEQJNshbs@public.gmane.org> wrote:


>> As you don't submit any patch for the dtsi, I assume that you expect
>> that this part will be done at board level. In this case as I wrote
>> above we are sure that all the board continue working without any need
>> to test them.
>
> No, this won't work without any changes to the Armada dtsi /
> dts files. As the SPI controller node needs to get moved
> for this 'reg' property to work (suggestion from Arnd).
>
> I've submitted 2 patches for the dtsi / dts files a short while
> ago:
>
> http://www.spinics.net/lists/arm-kernel/msg495524.html
> http://www.spinics.net/lists/arm-kernel/msg495523.html
>
> When this SPI driver patch gets accepted, I'll send an updated
> patchset for the dtsi / dts files.

Unless I am wrong the SPI driver patch got accepted, but I didn't see an
updated patchset for the dtsi / dts files. Did I miss it?

Else would you ming to send them? Then I will be able to apply them on
the mvebu tree.

Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] spi: orion.c: Add direct access mode

[Gregory CLEMENT]

Hi Stefan,
 
 On mer., avril 20 2016, Stefan Roese <sr@denx.de> wrote:


>> As you don't submit any patch for the dtsi, I assume that you expect
>> that this part will be done at board level. In this case as I wrote
>> above we are sure that all the board continue working without any need
>> to test them.
>
> No, this won't work without any changes to the Armada dtsi /
> dts files. As the SPI controller node needs to get moved
> for this 'reg' property to work (suggestion from Arnd).
>
> I've submitted 2 patches for the dtsi / dts files a short while
> ago:
>
> http://www.spinics.net/lists/arm-kernel/msg495524.html
> http://www.spinics.net/lists/arm-kernel/msg495523.html
>
> When this SPI driver patch gets accepted, I'll send an updated
> patchset for the dtsi / dts files.

Unless I am wrong the SPI driver patch got accepted, but I didn't see an
updated patchset for the dtsi / dts files. Did I miss it?

Else would you ming to send them? Then I will be able to apply them on
the mvebu tree.

Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

Hi Gregory,

On 16.06.2016 11:23, Gregory CLEMENT wrote:
>   On mer., avril 20 2016, Stefan Roese <sr-ynQEQJNshbs@public.gmane.org> wrote:
>
>
>>> As you don't submit any patch for the dtsi, I assume that you expect
>>> that this part will be done at board level. In this case as I wrote
>>> above we are sure that all the board continue working without any need
>>> to test them.
>>
>> No, this won't work without any changes to the Armada dtsi /
>> dts files. As the SPI controller node needs to get moved
>> for this 'reg' property to work (suggestion from Arnd).
>>
>> I've submitted 2 patches for the dtsi / dts files a short while
>> ago:
>>
>> http://www.spinics.net/lists/arm-kernel/msg495524.html
>> http://www.spinics.net/lists/arm-kernel/msg495523.html
>>
>> When this SPI driver patch gets accepted, I'll send an updated
>> patchset for the dtsi / dts files.
>
> Unless I am wrong the SPI driver patch got accepted,

Correct. Its in linux-next now.

> but I didn't see an
> updated patchset for the dtsi / dts files. Did I miss it?

No, you didn't miss it.

> Else would you ming to send them? Then I will be able to apply them on
> the mvebu tree.

Its on my list. Thanks for reminding me. I'll get to working on this
next week and will send an updated patch series then.

Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] spi: orion.c: Add direct access mode

[Stefan Roese]

Hi Gregory,

On 16.06.2016 11:23, Gregory CLEMENT wrote:
>   On mer., avril 20 2016, Stefan Roese <sr@denx.de> wrote:
>
>
>>> As you don't submit any patch for the dtsi, I assume that you expect
>>> that this part will be done at board level. In this case as I wrote
>>> above we are sure that all the board continue working without any need
>>> to test them.
>>
>> No, this won't work without any changes to the Armada dtsi /
>> dts files. As the SPI controller node needs to get moved
>> for this 'reg' property to work (suggestion from Arnd).
>>
>> I've submitted 2 patches for the dtsi / dts files a short while
>> ago:
>>
>> http://www.spinics.net/lists/arm-kernel/msg495524.html
>> http://www.spinics.net/lists/arm-kernel/msg495523.html
>>
>> When this SPI driver patch gets accepted, I'll send an updated
>> patchset for the dtsi / dts files.
>
> Unless I am wrong the SPI driver patch got accepted,

Correct. Its in linux-next now.

> but I didn't see an
> updated patchset for the dtsi / dts files. Did I miss it?

No, you didn't miss it.

> Else would you ming to send them? Then I will be able to apply them on
> the mvebu tree.

Its on my list. Thanks for reminding me. I'll get to working on this
next week and will send an updated patch series then.

Thanks,
Stefan