[LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Ranjit Waghmode]

This series adds dual parallel mode support for Zynq Ultrascale+
MPSoC GQSPI controller driver.

What is dual parallel mode?
---------------------------
ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities:
1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
2) Chip selects and clock are shared to both the flash devices
3) This mode is targeted for faster read/write speed and also doubles the size
4) Commands/data can be transmitted/received from both the devices(mirror),
   or only upper or only lower flash memory devices.
5) Data arrangement:
   With stripe enabled,
   Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
   Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.

This series also updated MTD layer files for adding parallel mode support.

1) Added Support for two flashes
2) Support to enable/disable data stripe as and when required.
3) Added required parameters to spi_nor structure. Initialized all
   added parameters in spi_nor_scan()
4) Added support for dual parallel in spi_nor_read/write/erase functions by:
   a) Increasing page_size, sector_size, erase_size and toatal flash size
      as and when required.
   b) Dividing address by 2
   c) Updating spi->master->flags for qspi driver to change CS
5) Updated read_sr() to get status of both flashes
6) Also updated read_fsr() to get status of both flashes

These all are very high level changes and expected to make an idea clear.
Comments and suggestions are always welcomed

---
V2 Changes:
a) Splitted patches based on logical changes
b) Added error handling for newly added APIs in SPI core
---

Ranjit Waghmode (4):
  spi: add support of two chip selects & data stripe
  mtd: add spi_device instance to spi_nor struct
  spi-nor: add dual parallel mode support
  spi: zynqmp: gqspi: add support for dual parallel mode configuration

 drivers/mtd/devices/m25p80.c   |  1 +
 drivers/mtd/spi-nor/spi-nor.c  | 91 +++++++++++++++++++++++++++++++++---------
 drivers/spi/spi-zynqmp-gqspi.c | 24 ++++++++++-
 drivers/spi/spi.c              |  8 ++++
 include/linux/mtd/spi-nor.h    |  3 ++
 include/linux/spi/spi.h        | 11 +++++
 6 files changed, 118 insertions(+), 20 deletions(-)

--
2.1.2

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

[LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe

[Ranjit Waghmode]

To support dual parallel mode operation of ZynqMP GQSPI controller
following API's are added inside the core:

- Added API to support two chip selects:

  Dual parallel mode supports two SPI flash memories operating in
  parallel i.e 8 I/O lines.
  Chip selects and clock are shared to both the flash devices.
  So newly added API will help in enabling both the chips.

- Added API to support data stripe feature:

  with data stripe enabled,
  even bytes i.e. 0, 2, 4,... are transmitted on lower data bus
  odd bytes i.e. 1, 3, 5,.. are transmitted on upper data bus.

Signed-off-by: Ranjit Waghmode <ranjit.waghmode-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
---
V2 Changes:
- Added error handling condition for newly added features
---
 drivers/spi/spi.c       |  8 ++++++++
 include/linux/spi/spi.h | 11 +++++++++++
 2 files changed, 19 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index cf8b91b..22e8e7f 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1828,6 +1828,14 @@ static int __spi_validate(struct spi_device *spi, struct spi_message *message)
 	if (list_empty(&message->transfers))
 		return -EINVAL;

+	/*
+	 * Data stripe option is selected if and only if when
+	 * two chips are enabled
+	 */
+	if ((master->flags & SPI_MASTER_DATA_STRIPE)
+		&& !(master->flags & SPI_MASTER_BOTH_CS))
+			return -EINVAL;
+
 	/* Half-duplex links include original MicroWire, and ones with
 	 * only one data pin like SPI_3WIRE (switches direction) or where
 	 * either MOSI or MISO is missing.  They can also be caused by
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index d673072..53d3bc6 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -355,6 +355,17 @@ struct spi_master {
 #define SPI_MASTER_NO_TX	BIT(2)		/* can't do buffer write */
 #define SPI_MASTER_MUST_RX      BIT(3)		/* requires rx */
 #define SPI_MASTER_MUST_TX      BIT(4)		/* requires tx */
+	/* Controller may support data stripe feature when more than one
+	 * chips are present.
+	 * Setting data stripe will send data in following manner:
+	 * -> even bytes i.e. 0, 2, 4,... are transmitted on lower data bus
+	 * -> odd bytes i.e. 1, 3, 5,.. are transmitted on upper data bus
+	 */
+#define SPI_MASTER_DATA_STRIPE		BIT(7)		/* support data stripe */
+	/* Controller may support more than one chip.
+	 * This flag will enable that feature.
+	 */
+#define SPI_MASTER_BOTH_CS		BIT(8)		/* enable both chips */

 	/* lock and mutex for SPI bus locking */
 	spinlock_t		bus_lock_spinlock;
--
2.1.2

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

[LINUX RFC v2 2/4] mtd: add spi_device instance to spi_nor struct

[Ranjit Waghmode]

This patch adds struct spi_device instacne to the spi_nor structure

Signed-off-by: Ranjit Waghmode <ranjit.waghmode-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
---
V2 Changes:
This is new patch, basically splitted on request of Mark Brown
---
 drivers/mtd/devices/m25p80.c | 1 +
 include/linux/mtd/spi-nor.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index d313f948b..174ed0f 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -207,6 +207,7 @@ static int m25p_probe(struct spi_device *spi)
 	spi_set_drvdata(spi, flash);
 	flash->mtd.priv = nor;
 	flash->spi = spi;
+	nor->spi = spi;

 	if (spi->mode & SPI_RX_QUAD)
 		mode = SPI_NOR_QUAD;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index e540952..1705dc3 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -163,6 +163,7 @@ struct spi_nor {
 	struct mtd_info		*mtd;
 	struct mutex		lock;
 	struct device		*dev;
+	struct spi_device	*spi;
 	u32			page_size;
 	u8			addr_width;
 	u8			erase_opcode;
--
2.1.2

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

[LINUX RFC v2 3/4] spi-nor: add dual parallel mode support

[Ranjit Waghmode]

This patch adds support for dual parallel configuration by:

- Adding required parameters like isparallel and shift to spi_nor structure.
- Initializing all added parameters in spi_nor_scan()
- Updating read_sr() and read_fsr() for getting status of both flashes
- Increasing page_size, sector_size, erase_size and toatal flash size
  as and when required.
- Dividing address by 2
- Updating spi->master->flags for qspi driver to change CS

Signed-off-by: Ranjit Waghmode <ranjit.waghmode-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
---
V2 Changes:
Splitted to separate MTD layer changes from SPI core changes
---
 drivers/mtd/spi-nor/spi-nor.c | 91 ++++++++++++++++++++++++++++++++++---------
 include/linux/mtd/spi-nor.h   |  2 +
 2 files changed, 74 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d78831b..6a2e80b 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -22,6 +22,7 @@
 #include <linux/of_platform.h>
 #include <linux/spi/flash.h>
 #include <linux/mtd/spi-nor.h>
+#include <linux/spi/spi.h>

 /* Define max times to check status register before we give up. */
 #define	MAX_READY_WAIT_JIFFIES	(40 * HZ) /* M25P16 specs 40s max chip erase */
@@ -69,15 +70,24 @@ static const struct spi_device_id *spi_nor_match_id(const char *name);
 static int read_sr(struct spi_nor *nor)
 {
 	int ret;
-	u8 val;
+	u8 val[2];

-	ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
-	if (ret < 0) {
-		pr_err("error %d reading SR\n", (int) ret);
-		return ret;
+	if (nor->isparallel) {
+		ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 2);
+		if (ret < 0) {
+			pr_err("error %d reading SR\n", (int) ret);
+			return ret;
+		}
+		val[0] |= val[1];
+	} else {
+		ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 1);
+		if (ret < 0) {
+			pr_err("error %d reading SR\n", (int) ret);
+			return ret;
+		}
 	}

-	return val;
+	return val[0];
 }

 /*
@@ -87,16 +97,24 @@ static int read_sr(struct spi_nor *nor)
  */
 static int read_fsr(struct spi_nor *nor)
 {
-	int ret;
-	u8 val;
+	int ret, size;
+	u8 val[2];
+
+	size = 1;
+	val[1] = 0xff;
+
+	if (nor->isparallel)
+		size = 2;

-	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
+	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], size);
 	if (ret < 0) {
 		pr_err("error %d reading FSR\n", ret);
 		return ret;
 	}

-	return val;
+	val[0] &= val[1];
+
+	return val[0];
 }

 /*
@@ -317,6 +335,9 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
 	if (ret)
 		return ret;

+	if (nor->isparallel)
+		nor->spi->master->flags |= SPI_MASTER_DATA_STRIPE;
+
 	/* whole-chip erase? */
 	if (len == mtd->size) {
 		write_enable(nor);
@@ -340,6 +361,8 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
 		while (len) {
 			write_enable(nor);

+			addr = addr >> nor->shift;
+
 			if (nor->erase(nor, addr)) {
 				ret = -EIO;
 				goto erase_err;
@@ -360,19 +383,22 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)

 	instr->state = MTD_ERASE_DONE;
 	mtd_erase_callback(instr);
-
+	if (nor->isparallel)
+		nor->spi->master->flags &= ~SPI_MASTER_DATA_STRIPE;
 	return ret;

 erase_err:
 	spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_ERASE);
 	instr->state = MTD_ERASE_FAILED;
+	if (nor->isparallel)
+		nor->spi->master->flags &= ~SPI_MASTER_DATA_STRIPE;
 	return ret;
 }

 static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
 {
 	struct mtd_info *mtd = nor->mtd;
-	uint32_t offset = ofs;
+	uint32_t offset = ofs >> nor->shift;
 	uint8_t status_old, status_new;
 	int ret = 0;

@@ -406,7 +432,7 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
 static int stm_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
 {
 	struct mtd_info *mtd = nor->mtd;
-	uint32_t offset = ofs;
+	uint32_t offset = ofs >> nor->shift;
 	uint8_t status_old, status_new;
 	int ret = 0;

@@ -446,6 +472,8 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
 	if (ret)
 		return ret;

+	ofs = ofs >> nor->shift;
+
 	ret = nor->flash_lock(nor, ofs, len);

 	spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_UNLOCK);
@@ -461,6 +489,8 @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
 	if (ret)
 		return ret;

+	ofs = ofs >> nor->shift;
+
 	ret = nor->flash_unlock(nor, ofs, len);

 	spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_LOCK);
@@ -738,7 +768,13 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
 	if (ret)
 		return ret;

-	ret = nor->read(nor, from, len, retlen, buf);
+	if (nor->isparallel)
+		nor->spi->master->flags |= SPI_MASTER_DATA_STRIPE;
+
+	ret = nor->read(nor, from >> nor->shift, len, retlen, buf);
+
+	if (nor->isparallel)
+		nor->spi->master->flags &= ~SPI_MASTER_DATA_STRIPE;

 	spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_READ);
 	return ret;
@@ -834,11 +870,11 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,

 	/* do all the bytes fit onto one page? */
 	if (page_offset + len <= nor->page_size) {
-		nor->write(nor, to, len, retlen, buf);
+		nor->write(nor, to >> nor->shift, len, retlen, buf);
 	} else {
 		/* the size of data remaining on the first page */
 		page_size = nor->page_size - page_offset;
-		nor->write(nor, to, page_size, retlen, buf);
+		nor->write(nor, to >> nor->shift, page_size, retlen, buf);

 		/* write everything in nor->page_size chunks */
 		for (i = page_size; i < len; i += page_size) {
@@ -852,12 +888,15 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,

 			write_enable(nor);

-			nor->write(nor, to + i, page_size, retlen, buf + i);
+			nor->write(nor, (to + i) >> nor->shift, page_size,
+					retlen, buf + i);
 		}
 	}

 	ret = spi_nor_wait_till_ready(nor);
 write_err:
+	if (nor->isparallel)
+		nor->spi->master->flags &= ~SPI_MASTER_DATA_STRIPE;
 	spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_WRITE);
 	return ret;
 }
@@ -1073,6 +1112,20 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 	mtd->_erase = spi_nor_erase;
 	mtd->_read = spi_nor_read;

+#ifdef CONFIG_OF
+	struct device_node *np_spi = of_get_next_parent(np);
+	u32 is_dual;
+
+	if (of_property_read_u32(np_spi, "is-dual", &is_dual) > 0) {
+		nor->shift = 1;
+		info->sector_size <<= nor->shift;
+		info->page_size <<= nor->shift;
+		mtd->size <<= nor->shift;
+		nor->isparallel = 1;
+		nor->spi->master->flags |= SPI_MASTER_BOTH_CS;
+	}
+#endif
+
 	/* nor protection support for STmicro chips */
 	if (JEDEC_MFR(info) == CFI_MFR_ST) {
 		nor->flash_lock = stm_lock;
@@ -1097,10 +1150,10 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 	/* prefer "small sector" erase if possible */
 	if (info->flags & SECT_4K) {
 		nor->erase_opcode = SPINOR_OP_BE_4K;
-		mtd->erasesize = 4096;
+		mtd->erasesize = 4096 << nor->shift;
 	} else if (info->flags & SECT_4K_PMC) {
 		nor->erase_opcode = SPINOR_OP_BE_4K_PMC;
-		mtd->erasesize = 4096;
+		mtd->erasesize = 4096 << nor->shift;
 	} else
 #endif
 	{
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 1705dc3..6ef25a8 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -171,6 +171,8 @@ struct spi_nor {
 	u8			read_dummy;
 	u8			program_opcode;
 	enum read_mode		flash_read;
+	bool			shift;
+	bool			isparallel;
 	bool			sst_write_second;
 	u32			flags;
 	struct spi_nor_xfer_cfg	cfg;
--
2.1.2

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

[LINUX RFC v2 4/4] spi: zynqmp: gqspi: add support for dual parallel mode configuration

[Ranjit Waghmode]

This patch adds support of dual parallel mode configuration
for Zynq Ultrascale+ MPSoC GQSPI controller driver.

Signed-off-by: Ranjit Waghmode <ranjit.waghmode-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
---
V2 Changes:
- No change in this patch
---
 drivers/spi/spi-zynqmp-gqspi.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index f23f36e..7a72781 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -153,6 +153,7 @@ enum mode_type {GQSPI_MODE_IO, GQSPI_MODE_DMA};
  * @dma_rx_bytes:	Remaining bytes to receive by DMA mode
  * @dma_addr:		DMA address after mapping the kernel buffer
  * @genfifoentry:	Used for storing the genfifoentry instruction.
+ * @isinstr:		To determine whether the transfer is instruction
  * @mode:		Defines the mode in which QSPI is operating
  */
 struct zynqmp_qspi {
@@ -170,6 +171,7 @@ struct zynqmp_qspi {
 	u32 dma_rx_bytes;
 	dma_addr_t dma_addr;
 	u32 genfifoentry;
+	bool isinstr;
 	enum mode_type mode;
 };

@@ -405,9 +407,20 @@ static void zynqmp_qspi_chipselect(struct spi_device *qspi, bool is_high)
 	genfifoentry |= GQSPI_GENFIFO_MODE_SPI;
 	genfifoentry |= xqspi->genfifobus;

+	if (qspi->master->flags & SPI_MASTER_BOTH_CS) {
+		zynqmp_gqspi_selectslave(xqspi,
+				GQSPI_SELECT_FLASH_CS_BOTH,
+				GQSPI_SELECT_FLASH_BUS_BOTH);
+	} else {
+		zynqmp_gqspi_selectslave(xqspi,
+				GQSPI_SELECT_FLASH_CS_LOWER,
+				GQSPI_SELECT_FLASH_BUS_LOWER);
+	}
+
 	if (!is_high) {
 		genfifoentry |= xqspi->genfifocs;
 		genfifoentry |= GQSPI_GENFIFO_CS_SETUP;
+		xqspi->isinstr = true;
 	} else {
 		genfifoentry |= GQSPI_GENFIFO_CS_HOLD;
 	}
@@ -664,6 +677,7 @@ static irqreturn_t zynqmp_qspi_irq(int irq, void *dev_id)
 	if ((xqspi->bytes_to_receive == 0) && (xqspi->bytes_to_transfer == 0)
 			&& ((status & GQSPI_IRQ_MASK) == GQSPI_IRQ_MASK)) {
 		zynqmp_gqspi_write(xqspi, GQSPI_IDR_OFST, GQSPI_ISR_IDR_MASK);
+		xqspi->isinstr = false;
 		spi_finalize_current_transfer(master);
 		ret = IRQ_HANDLED;
 	}
@@ -827,6 +841,9 @@ static int zynqmp_qspi_start_transfer(struct spi_master *master,
 	genfifoentry |= xqspi->genfifocs;
 	genfifoentry |= xqspi->genfifobus;

+	if ((!xqspi->isinstr) && (master->flags & SPI_MASTER_DATA_STRIPE))
+		genfifoentry |= GQSPI_GENFIFO_STRIPE;
+
 	zynqmp_qspi_txrxsetup(xqspi, transfer, &genfifoentry);

 	if (xqspi->mode == GQSPI_MODE_DMA)
@@ -983,6 +1000,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 	struct zynqmp_qspi *xqspi;
 	struct resource *res;
 	struct device *dev = &pdev->dev;
+	u32 num_cs;

 	master = spi_alloc_master(&pdev->dev, sizeof(*xqspi));
 	if (!master)
@@ -1043,7 +1061,11 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto clk_dis_all;
 	}

-	master->num_chipselect = GQSPI_DEFAULT_NUM_CS;
+	ret = of_property_read_u32(pdev->dev.of_node, "num-cs", &num_cs);
+	if (ret < 0)
+		master->num_chipselect = GQSPI_DEFAULT_NUM_CS;
+	else
+		master->num_chipselect = num_cs;

 	master->setup = zynqmp_qspi_setup;
 	master->set_cs = zynqmp_qspi_chipselect;
--
2.1.2

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

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Marek Vasut]

On Wednesday, August 26, 2015 at 08:26:03 AM, Ranjit Waghmode wrote:
> This series adds dual parallel mode support for Zynq Ultrascale+
> MPSoC GQSPI controller driver.
> 
> What is dual parallel mode?
> ---------------------------
> ZynqMP GQSPI controller supports Dual Parallel mode with following
> functionalities: 1) Supporting two SPI flash memories operating in
> parallel. 8 I/O lines. 2) Chip selects and clock are shared to both the
> flash devices
> 3) This mode is targeted for faster read/write speed and also doubles the
> size 4) Commands/data can be transmitted/received from both the
> devices(mirror), or only upper or only lower flash memory devices.
> 5) Data arrangement:
>    With stripe enabled,
>    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.

This might be a dumb question, but why don't you just treat this as an
SPI NOR flash with 8-bit bus ?

Best regards,
Marek Vasut

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Jagan Teki]

On 26 August 2015 at 11:56, Ranjit Waghmode <ranjit.waghmode@xilinx.com> wrote:
> This series adds dual parallel mode support for Zynq Ultrascale+
> MPSoC GQSPI controller driver.
>
> What is dual parallel mode?
> ---------------------------
> ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities:
> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
> 2) Chip selects and clock are shared to both the flash devices
> 3) This mode is targeted for faster read/write speed and also doubles the size
> 4) Commands/data can be transmitted/received from both the devices(mirror),
>    or only upper or only lower flash memory devices.
> 5) Data arrangement:
>    With stripe enabled,
>    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
>
> This series also updated MTD layer files for adding parallel mode support.
>
> 1) Added Support for two flashes
> 2) Support to enable/disable data stripe as and when required.
> 3) Added required parameters to spi_nor structure. Initialized all
>    added parameters in spi_nor_scan()
> 4) Added support for dual parallel in spi_nor_read/write/erase functions by:
>    a) Increasing page_size, sector_size, erase_size and toatal flash size
>       as and when required.
>    b) Dividing address by 2
>    c) Updating spi->master->flags for qspi driver to change CS
> 5) Updated read_sr() to get status of both flashes
> 6) Also updated read_fsr() to get status of both flashes
>
> These all are very high level changes and expected to make an idea clear.
> Comments and suggestions are always welcomed
>
> ---
> V2 Changes:
> a) Splitted patches based on logical changes
> b) Added error handling for newly added APIs in SPI core
> ---
>
> Ranjit Waghmode (4):
>   spi: add support of two chip selects & data stripe
>   mtd: add spi_device instance to spi_nor struct
>   spi-nor: add dual parallel mode support
>   spi: zynqmp: gqspi: add support for dual parallel mode configuration

I don't find any previous discussion about way to inform flash
dual-ness into spi-nor
from spi drivers.

Here is my idea, probably others may think same.
Informing dual_flash from drivers/spi through flags or any other mode
bits is not a better approach as dual flash feature is specific to
spi-nor flash controller (controller specially designed for spi-nor
flash not the generic spi controller).  So if the driver sits on
drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash
specific things to spi-nor as it's not touching generic spi stack in
Linux. But there is a defined-drawback if the driver is moved to
drivers/mtd/spi-nor ie it can't use spi core API's at-all.

thanks!
-- 
Jagan | openedev.

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[punnaiah choudary kalluri]

On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki <jteki-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org> wrote:
> On 26 August 2015 at 11:56, Ranjit Waghmode <ranjit.waghmode-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>> This series adds dual parallel mode support for Zynq Ultrascale+
>> MPSoC GQSPI controller driver.
>>
>> What is dual parallel mode?
>> ---------------------------
>> ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities:
>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
>> 2) Chip selects and clock are shared to both the flash devices
>> 3) This mode is targeted for faster read/write speed and also doubles the size
>> 4) Commands/data can be transmitted/received from both the devices(mirror),
>>    or only upper or only lower flash memory devices.
>> 5) Data arrangement:
>>    With stripe enabled,
>>    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>>    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
>>
>> This series also updated MTD layer files for adding parallel mode support.
>>
>> 1) Added Support for two flashes
>> 2) Support to enable/disable data stripe as and when required.
>> 3) Added required parameters to spi_nor structure. Initialized all
>>    added parameters in spi_nor_scan()
>> 4) Added support for dual parallel in spi_nor_read/write/erase functions by:
>>    a) Increasing page_size, sector_size, erase_size and toatal flash size
>>       as and when required.
>>    b) Dividing address by 2
>>    c) Updating spi->master->flags for qspi driver to change CS
>> 5) Updated read_sr() to get status of both flashes
>> 6) Also updated read_fsr() to get status of both flashes
>>
>> These all are very high level changes and expected to make an idea clear.
>> Comments and suggestions are always welcomed
>>
>> ---
>> V2 Changes:
>> a) Splitted patches based on logical changes
>> b) Added error handling for newly added APIs in SPI core
>> ---
>>
>> Ranjit Waghmode (4):
>>   spi: add support of two chip selects & data stripe
>>   mtd: add spi_device instance to spi_nor struct
>>   spi-nor: add dual parallel mode support
>>   spi: zynqmp: gqspi: add support for dual parallel mode configuration
>
> I don't find any previous discussion about way to inform flash
> dual-ness into spi-nor
> from spi drivers.
>
> Here is my idea, probably others may think same.
> Informing dual_flash from drivers/spi through flags or any other mode
> bits is not a better approach as dual flash feature is specific to
> spi-nor flash controller (controller specially designed for spi-nor
> flash not the generic spi controller).  So if the driver sits on
> drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash
> specific things to spi-nor as it's not touching generic spi stack in
> Linux. But there is a defined-drawback if the driver is moved to
> drivers/mtd/spi-nor ie it can't use spi core API's at-all.

Xilinx GQSPI is a generic quad spi controller. The primary goal is to support
Generic/Future command sequences and Future NOR/NAND flash devices.
This core can also be used for legacy SPI devices. Due to the generic nature
of the core, software can generate any command sequence. It also has additional
features like parallel and stacked configurations to double the data
rate and size.
Accessing spi-nor flash device is one particular use case and like
that there will be
many. So, we decided to keep this driver in generic spi framework and
that is the ideal
thing to do for the GQSPI controller.

Regards,
Punnaiah

>
> thanks!
> --
> Jagan | openedev.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Jagan Teki]

On 26 August 2015 at 21:02, punnaiah choudary kalluri
<punnaia-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki <jteki-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org> wrote:
>> On 26 August 2015 at 11:56, Ranjit Waghmode <ranjit.waghmode-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>> This series adds dual parallel mode support for Zynq Ultrascale+
>>> MPSoC GQSPI controller driver.
>>>
>>> What is dual parallel mode?
>>> ---------------------------
>>> ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities:
>>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
>>> 2) Chip selects and clock are shared to both the flash devices
>>> 3) This mode is targeted for faster read/write speed and also doubles the size
>>> 4) Commands/data can be transmitted/received from both the devices(mirror),
>>>    or only upper or only lower flash memory devices.
>>> 5) Data arrangement:
>>>    With stripe enabled,
>>>    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>>>    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
>>>
>>> This series also updated MTD layer files for adding parallel mode support.
>>>
>>> 1) Added Support for two flashes
>>> 2) Support to enable/disable data stripe as and when required.
>>> 3) Added required parameters to spi_nor structure. Initialized all
>>>    added parameters in spi_nor_scan()
>>> 4) Added support for dual parallel in spi_nor_read/write/erase functions by:
>>>    a) Increasing page_size, sector_size, erase_size and toatal flash size
>>>       as and when required.
>>>    b) Dividing address by 2
>>>    c) Updating spi->master->flags for qspi driver to change CS
>>> 5) Updated read_sr() to get status of both flashes
>>> 6) Also updated read_fsr() to get status of both flashes
>>>
>>> These all are very high level changes and expected to make an idea clear.
>>> Comments and suggestions are always welcomed
>>>
>>> ---
>>> V2 Changes:
>>> a) Splitted patches based on logical changes
>>> b) Added error handling for newly added APIs in SPI core
>>> ---
>>>
>>> Ranjit Waghmode (4):
>>>   spi: add support of two chip selects & data stripe
>>>   mtd: add spi_device instance to spi_nor struct
>>>   spi-nor: add dual parallel mode support
>>>   spi: zynqmp: gqspi: add support for dual parallel mode configuration
>>
>> I don't find any previous discussion about way to inform flash
>> dual-ness into spi-nor
>> from spi drivers.
>>
>> Here is my idea, probably others may think same.
>> Informing dual_flash from drivers/spi through flags or any other mode
>> bits is not a better approach as dual flash feature is specific to
>> spi-nor flash controller (controller specially designed for spi-nor
>> flash not the generic spi controller).  So if the driver sits on
>> drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash
>> specific things to spi-nor as it's not touching generic spi stack in
>> Linux. But there is a defined-drawback if the driver is moved to
>> drivers/mtd/spi-nor ie it can't use spi core API's at-all.
>
> Xilinx GQSPI is a generic quad spi controller. The primary goal is to support
> Generic/Future command sequences and Future NOR/NAND flash devices.
> This core can also be used for legacy SPI devices. Due to the generic nature
> of the core, software can generate any command sequence. It also has additional
> features like parallel and stacked configurations to double the data
> rate and size.
> Accessing spi-nor flash device is one particular use case and like
> that there will be
> many. So, we decided to keep this driver in generic spi framework and
> that is the ideal
> thing to do for the GQSPI controller.

Yes, I understand the generic nature of the GQSPI and it's good to
have all-in-one like generic spi, spi-nor and spi-nand and more
together, but Linux stacks were implemented in such a way to support
the each type of controller with connected slaves separably for better
handling.

Currently GQSPI driver is added in drivers/spi as it supports generic
spi nature and now it enhanced more through flags for supporting
spi-nor, what if we add spi-nand support for the same controller? do
we add one more driver in spi-nand framework (drivers/mtd/spi-nand -
an on going implementation)? My only observation here is even if the
controller is more generic to support more number of device classes,
and adding same driver and populate the slave stuff through flags or
different kind of mechanism to different driver stack, this is not a
better approach I thought.

Based on the above comments, there is an approach to handle this
support and I'm not 100% sure whether this fits or not but we
implemented the same -  this is "probing child devices from parent"
(there was a discussion with Arnd earlier wrt this, but I'm unable to
get the mailing thread)

Added Arnd (probably will give more inputs or corrections)

Let me explain how we implemented on our design.
We have PCIe controller that support basic root complex handling, dma
and controller hotplug (not in-build pcie hp) and ideally we need to
write driver for handling root complex on drivers/pci/host and one
hotplug driver in drivers/pci and one more driver in drivers/dma for
handling pcie dma stuff. And some pcie calls need to navigate from
root complex driver to dma and hotplug driver that means there is call
transition from driver/pci to driver/dma which is absolutely not a
good approach (spi to spi-nor and spi-nand transition - in GQSPI case)

So the implementation we follow is like there is a pcie root complex
driver(probably generic spi driver in drivers/spi/*) and inside probe
we have register platform_device for hotplug (spi-nor) and dma
(spi-nand) and the dma driver in drivers/dma and hotplug driver in
driver/pci/ are platform drivers which is of legacy binding (not with
dts) so there should be a common dts for root complex driver
(drivers/spi/*) and individual child driver need to take those while
registering platform_device.

example pseudo:

drivers/dma/dma-child2.c

Legacy platform_driver binding and handling dma future as normal dma
driver, spi-nand in your case

drivers/pci/hotplug/hp-child1.c

Legacy platform_driver binding and handling hotplug future as normal
hotplug driver, spi-nor in your case.

drivers/pci/host/rc-parent-pci.c

static int rc_parent_pcie_probe_bridge(struct platform_device *pdev)
{
   // Generic rc handling (genric spi stuff)

   // Hotplug handling (spi-nor)
   - platform_device_alloc
   - assign need resources
   - register pdev using platform_device_add

    // DMA handling (spi-nand)
   - same as above
}

static const struct of_device_id rc_parent_pcie_match_table[] = {
        {.compatible = "abc,rc-parent",},
        {},
};

static struct platform_driver rc_parent_pcie_driver = {
        .driver = {
                   .name = "rc-parent",
                   .of_match_table = of_match_ptr(rc_parent_pcie_match_table),
        },
        .probe = rc_parent_pcie_probe_bridge,
};
module_platform_driver(rc_parent_pcie_driver);

I couldn't find any driver mainlined wrt this design, think more on
GQSPI front, whether this design fits well or not.

thanks!
-- 
Jagan | openedev.
--
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

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[punnaiah choudary kalluri]

On Thu, Aug 27, 2015 at 11:53 AM, Jagan Teki <jteki-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org> wrote:
> On 26 August 2015 at 21:02, punnaiah choudary kalluri
> <punnaia-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>> On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki <jteki-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org> wrote:
>>> On 26 August 2015 at 11:56, Ranjit Waghmode <ranjit.waghmode-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>>> This series adds dual parallel mode support for Zynq Ultrascale+
>>>> MPSoC GQSPI controller driver.
>>>>
>>>> What is dual parallel mode?
>>>> ---------------------------
>>>> ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities:
>>>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
>>>> 2) Chip selects and clock are shared to both the flash devices
>>>> 3) This mode is targeted for faster read/write speed and also doubles the size
>>>> 4) Commands/data can be transmitted/received from both the devices(mirror),
>>>>    or only upper or only lower flash memory devices.
>>>> 5) Data arrangement:
>>>>    With stripe enabled,
>>>>    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>>>>    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
<snip>
>>> I don't find any previous discussion about way to inform flash
>>> dual-ness into spi-nor
>>> from spi drivers.
>>>
>>> Here is my idea, probably others may think same.
>>> Informing dual_flash from drivers/spi through flags or any other mode
>>> bits is not a better approach as dual flash feature is specific to
>>> spi-nor flash controller (controller specially designed for spi-nor
>>> flash not the generic spi controller).  So if the driver sits on
>>> drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash
>>> specific things to spi-nor as it's not touching generic spi stack in
>>> Linux. But there is a defined-drawback if the driver is moved to
>>> drivers/mtd/spi-nor ie it can't use spi core API's at-all.
>>
>> Xilinx GQSPI is a generic quad spi controller. The primary goal is to support
>> Generic/Future command sequences and Future NOR/NAND flash devices.
>> This core can also be used for legacy SPI devices. Due to the generic nature
>> of the core, software can generate any command sequence. It also has additional
>> features like parallel and stacked configurations to double the data
>> rate and size.
>> Accessing spi-nor flash device is one particular use case and like
>> that there will be
>> many. So, we decided to keep this driver in generic spi framework and
>> that is the ideal
>> thing to do for the GQSPI controller.
>
> Yes, I understand the generic nature of the GQSPI and it's good to
> have all-in-one like generic spi, spi-nor and spi-nand and more
> together, but Linux stacks were implemented in such a way to support
> the each type of controller with connected slaves separably for better
> handling.

True and this is the reason we have controller drivers and protocol drivers.
GQSPI is the controller driver and spi-nor and spi-nand are the
protocol drivers.

>
> Currently GQSPI driver is added in drivers/spi as it supports generic
> spi nature and now it enhanced more through flags for supporting
> spi-nor, what if we add spi-nand support for the same controller? do
> we add one more driver in spi-nand framework (drivers/mtd/spi-nand -
> an on going implementation)? My only observation here is even if the
> controller is more generic to support more number of device classes,
> and adding same driver and populate the slave stuff through flags or
> different kind of mechanism to different driver stack, this is not a
> better approach I thought.

Just to clear, dual parallel( 2 CS and 8 IO lines) is not only specific
to flash parts, one can use for any other custom streaming protocols
I would say exporting dual parallel connection to protocol drivers is
something like depicting the spi bus topology to the protocol layer.

AFAIK, spi-nor and spi-nand are protocol drivers for accessing the
nor and nand flash devices sitting on the spi bus using the spi
controller driver.

Regards,
Punnaiah

>
> Based on the above comments, there is an approach to handle this
> support and I'm not 100% sure whether this fits or not but we
> implemented the same -  this is "probing child devices from parent"
> (there was a discussion with Arnd earlier wrt this, but I'm unable to
> get the mailing thread)
>
> Added Arnd (probably will give more inputs or corrections)
>
> Let me explain how we implemented on our design.
> We have PCIe controller that support basic root complex handling, dma
> and controller hotplug (not in-build pcie hp) and ideally we need to
> write driver for handling root complex on drivers/pci/host and one
> hotplug driver in drivers/pci and one more driver in drivers/dma for
> handling pcie dma stuff. And some pcie calls need to navigate from
> root complex driver to dma and hotplug driver that means there is call
> transition from driver/pci to driver/dma which is absolutely not a
> good approach (spi to spi-nor and spi-nand transition - in GQSPI case)
>
> So the implementation we follow is like there is a pcie root complex
> driver(probably generic spi driver in drivers/spi/*) and inside probe
> we have register platform_device for hotplug (spi-nor) and dma
> (spi-nand) and the dma driver in drivers/dma and hotplug driver in
> driver/pci/ are platform drivers which is of legacy binding (not with
> dts) so there should be a common dts for root complex driver
> (drivers/spi/*) and individual child driver need to take those while
> registering platform_device.
>
> example pseudo:
>
> drivers/dma/dma-child2.c
>
> Legacy platform_driver binding and handling dma future as normal dma
> driver, spi-nand in your case
>
> drivers/pci/hotplug/hp-child1.c
>
> Legacy platform_driver binding and handling hotplug future as normal
> hotplug driver, spi-nor in your case.
>
> drivers/pci/host/rc-parent-pci.c
>
> static int rc_parent_pcie_probe_bridge(struct platform_device *pdev)
> {
>    // Generic rc handling (genric spi stuff)
>
>    // Hotplug handling (spi-nor)
>    - platform_device_alloc
>    - assign need resources
>    - register pdev using platform_device_add
>
>     // DMA handling (spi-nand)
>    - same as above
> }
>
> static const struct of_device_id rc_parent_pcie_match_table[] = {
>         {.compatible = "abc,rc-parent",},
>         {},
> };
>
> static struct platform_driver rc_parent_pcie_driver = {
>         .driver = {
>                    .name = "rc-parent",
>                    .of_match_table = of_match_ptr(rc_parent_pcie_match_table),
>         },
>         .probe = rc_parent_pcie_probe_bridge,
> };
> module_platform_driver(rc_parent_pcie_driver);
>
> I couldn't find any driver mainlined wrt this design, think more on
> GQSPI front, whether this design fits well or not.
>
> thanks!
> --
> Jagan | openedev.
> --
> 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
--
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

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Jagan Teki]

On 27 August 2015 at 14:18, punnaiah choudary kalluri
<punnaia-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, Aug 27, 2015 at 11:53 AM, Jagan Teki <jteki-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org> wrote:
>> On 26 August 2015 at 21:02, punnaiah choudary kalluri
>> <punnaia-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>> On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki <jteki-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org> wrote:
>>>> On 26 August 2015 at 11:56, Ranjit Waghmode <ranjit.waghmode-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>>>> This series adds dual parallel mode support for Zynq Ultrascale+
>>>>> MPSoC GQSPI controller driver.
>>>>>
>>>>> What is dual parallel mode?
>>>>> ---------------------------
>>>>> ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities:
>>>>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
>>>>> 2) Chip selects and clock are shared to both the flash devices
>>>>> 3) This mode is targeted for faster read/write speed and also doubles the size
>>>>> 4) Commands/data can be transmitted/received from both the devices(mirror),
>>>>>    or only upper or only lower flash memory devices.
>>>>> 5) Data arrangement:
>>>>>    With stripe enabled,
>>>>>    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>>>>>    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
> <snip>
>>>> I don't find any previous discussion about way to inform flash
>>>> dual-ness into spi-nor
>>>> from spi drivers.
>>>>
>>>> Here is my idea, probably others may think same.
>>>> Informing dual_flash from drivers/spi through flags or any other mode
>>>> bits is not a better approach as dual flash feature is specific to
>>>> spi-nor flash controller (controller specially designed for spi-nor
>>>> flash not the generic spi controller).  So if the driver sits on
>>>> drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash
>>>> specific things to spi-nor as it's not touching generic spi stack in
>>>> Linux. But there is a defined-drawback if the driver is moved to
>>>> drivers/mtd/spi-nor ie it can't use spi core API's at-all.
>>>
>>> Xilinx GQSPI is a generic quad spi controller. The primary goal is to support
>>> Generic/Future command sequences and Future NOR/NAND flash devices.
>>> This core can also be used for legacy SPI devices. Due to the generic nature
>>> of the core, software can generate any command sequence. It also has additional
>>> features like parallel and stacked configurations to double the data
>>> rate and size.
>>> Accessing spi-nor flash device is one particular use case and like
>>> that there will be
>>> many. So, we decided to keep this driver in generic spi framework and
>>> that is the ideal
>>> thing to do for the GQSPI controller.
>>
>> Yes, I understand the generic nature of the GQSPI and it's good to
>> have all-in-one like generic spi, spi-nor and spi-nand and more
>> together, but Linux stacks were implemented in such a way to support
>> the each type of controller with connected slaves separably for better
>> handling.
>
> True and this is the reason we have controller drivers and protocol drivers.
> GQSPI is the controller driver and spi-nor and spi-nand are the
> protocol drivers.
>
>>
>> Currently GQSPI driver is added in drivers/spi as it supports generic
>> spi nature and now it enhanced more through flags for supporting
>> spi-nor, what if we add spi-nand support for the same controller? do
>> we add one more driver in spi-nand framework (drivers/mtd/spi-nand -
>> an on going implementation)? My only observation here is even if the
>> controller is more generic to support more number of device classes,
>> and adding same driver and populate the slave stuff through flags or
>> different kind of mechanism to different driver stack, this is not a
>> better approach I thought.
>
> Just to clear, dual parallel( 2 CS and 8 IO lines) is not only specific
> to flash parts, one can use for any other custom streaming protocols
> I would say exporting dual parallel connection to protocol drivers is
> something like depicting the spi bus topology to the protocol layer.

So dual parallel may not used for spi-nor flash it can also used other
spi slaves that's what your saying is it?

>
> AFAIK, spi-nor and spi-nand are protocol drivers for accessing the
> nor and nand flash devices sitting on the spi bus using the spi
> controller driver.

Yes, I do agree with your point, but though driver stacks are
different with same kind of bus here, I'm trying to spit the GQSPI
into 3 different controller drivers as Linux understand it and fit on
to Linux stack with out disturbing the generic-ness.

Assumption is GQSPI shall split to various platform_drivers (if each
platform driver treated as a controller) thought it made up of  spi
bus.

>>
>> Based on the above comments, there is an approach to handle this
>> support and I'm not 100% sure whether this fits or not but we
>> implemented the same -  this is "probing child devices from parent"
>> (there was a discussion with Arnd earlier wrt this, but I'm unable to
>> get the mailing thread)
>>
>> Added Arnd (probably will give more inputs or corrections)
>>
>> Let me explain how we implemented on our design.
>> We have PCIe controller that support basic root complex handling, dma
>> and controller hotplug (not in-build pcie hp) and ideally we need to
>> write driver for handling root complex on drivers/pci/host and one
>> hotplug driver in drivers/pci and one more driver in drivers/dma for
>> handling pcie dma stuff. And some pcie calls need to navigate from
>> root complex driver to dma and hotplug driver that means there is call
>> transition from driver/pci to driver/dma which is absolutely not a
>> good approach (spi to spi-nor and spi-nand transition - in GQSPI case)
>>
>> So the implementation we follow is like there is a pcie root complex
>> driver(probably generic spi driver in drivers/spi/*) and inside probe
>> we have register platform_device for hotplug (spi-nor) and dma
>> (spi-nand) and the dma driver in drivers/dma and hotplug driver in
>> driver/pci/ are platform drivers which is of legacy binding (not with
>> dts) so there should be a common dts for root complex driver
>> (drivers/spi/*) and individual child driver need to take those while
>> registering platform_device.
>>
>> example pseudo:
>>
>> drivers/dma/dma-child2.c
>>
>> Legacy platform_driver binding and handling dma future as normal dma
>> driver, spi-nand in your case
>>
>> drivers/pci/hotplug/hp-child1.c
>>
>> Legacy platform_driver binding and handling hotplug future as normal
>> hotplug driver, spi-nor in your case.
>>
>> drivers/pci/host/rc-parent-pci.c
>>
>> static int rc_parent_pcie_probe_bridge(struct platform_device *pdev)
>> {
>>    // Generic rc handling (genric spi stuff)
>>
>>    // Hotplug handling (spi-nor)
>>    - platform_device_alloc
>>    - assign need resources
>>    - register pdev using platform_device_add
>>
>>     // DMA handling (spi-nand)
>>    - same as above
>> }
>>
>> static const struct of_device_id rc_parent_pcie_match_table[] = {
>>         {.compatible = "abc,rc-parent",},
>>         {},
>> };
>>
>> static struct platform_driver rc_parent_pcie_driver = {
>>         .driver = {
>>                    .name = "rc-parent",
>>                    .of_match_table = of_match_ptr(rc_parent_pcie_match_table),
>>         },
>>         .probe = rc_parent_pcie_probe_bridge,
>> };
>> module_platform_driver(rc_parent_pcie_driver);
>>
>> I couldn't find any driver mainlined wrt this design, think more on
>> GQSPI front, whether this design fits well or not.

thanks!
-- 
Jagan | openedev.
--
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

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[punnaiah choudary kalluri]

On Thu, Aug 27, 2015 at 3:45 PM, Jagan Teki <jteki-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org> wrote:
> On 27 August 2015 at 14:18, punnaiah choudary kalluri
> <punnaia-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>> On Thu, Aug 27, 2015 at 11:53 AM, Jagan Teki <jteki-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org> wrote:
>>> On 26 August 2015 at 21:02, punnaiah choudary kalluri
>>> <punnaia-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>>> On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki <jteki-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org> wrote:
>>>>> On 26 August 2015 at 11:56, Ranjit Waghmode <ranjit.waghmode-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>>>>> This series adds dual parallel mode support for Zynq Ultrascale+
>>>>>> MPSoC GQSPI controller driver.
>>>>>>
>>>>>> What is dual parallel mode?
>>>>>> ---------------------------
>>>>>> ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities:
>>>>>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
>>>>>> 2) Chip selects and clock are shared to both the flash devices
>>>>>> 3) This mode is targeted for faster read/write speed and also doubles the size
>>>>>> 4) Commands/data can be transmitted/received from both the devices(mirror),
>>>>>>    or only upper or only lower flash memory devices.
>>>>>> 5) Data arrangement:
>>>>>>    With stripe enabled,
>>>>>>    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>>>>>>    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
>> <snip>
>>>>> I don't find any previous discussion about way to inform flash
>>>>> dual-ness into spi-nor
>>>>> from spi drivers.
>>>>>
>>>>> Here is my idea, probably others may think same.
>>>>> Informing dual_flash from drivers/spi through flags or any other mode
>>>>> bits is not a better approach as dual flash feature is specific to
>>>>> spi-nor flash controller (controller specially designed for spi-nor
>>>>> flash not the generic spi controller).  So if the driver sits on
>>>>> drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash
>>>>> specific things to spi-nor as it's not touching generic spi stack in
>>>>> Linux. But there is a defined-drawback if the driver is moved to
>>>>> drivers/mtd/spi-nor ie it can't use spi core API's at-all.
>>>>
>>>> Xilinx GQSPI is a generic quad spi controller. The primary goal is to support
>>>> Generic/Future command sequences and Future NOR/NAND flash devices.
>>>> This core can also be used for legacy SPI devices. Due to the generic nature
>>>> of the core, software can generate any command sequence. It also has additional
>>>> features like parallel and stacked configurations to double the data
>>>> rate and size.
>>>> Accessing spi-nor flash device is one particular use case and like
>>>> that there will be
>>>> many. So, we decided to keep this driver in generic spi framework and
>>>> that is the ideal
>>>> thing to do for the GQSPI controller.
>>>
>>> Yes, I understand the generic nature of the GQSPI and it's good to
>>> have all-in-one like generic spi, spi-nor and spi-nand and more
>>> together, but Linux stacks were implemented in such a way to support
>>> the each type of controller with connected slaves separably for better
>>> handling.
>>
>> True and this is the reason we have controller drivers and protocol drivers.
>> GQSPI is the controller driver and spi-nor and spi-nand are the
>> protocol drivers.
>>
>>>
>>> Currently GQSPI driver is added in drivers/spi as it supports generic
>>> spi nature and now it enhanced more through flags for supporting
>>> spi-nor, what if we add spi-nand support for the same controller? do
>>> we add one more driver in spi-nand framework (drivers/mtd/spi-nand -
>>> an on going implementation)? My only observation here is even if the
>>> controller is more generic to support more number of device classes,
>>> and adding same driver and populate the slave stuff through flags or
>>> different kind of mechanism to different driver stack, this is not a
>>> better approach I thought.
>>
>> Just to clear, dual parallel( 2 CS and 8 IO lines) is not only specific
>> to flash parts, one can use for any other custom streaming protocols
>> I would say exporting dual parallel connection to protocol drivers is
>> something like depicting the spi bus topology to the protocol layer.
>
> So dual parallel may not used for spi-nor flash it can also used other
> spi slaves that's what your saying is it?

Yes. As i said above, the main intention of this feature is to improve
the data rate with an overhead of few IO lines.

>
>>
>> AFAIK, spi-nor and spi-nand are protocol drivers for accessing the
>> nor and nand flash devices sitting on the spi bus using the spi
>> controller driver.
>
> Yes, I do agree with your point, but though driver stacks are
> different with same kind of bus here, I'm trying to spit the GQSPI
> into 3 different controller drivers as Linux understand it and fit on
> to Linux stack with out disturbing the generic-ness.

 I feel this is not a nice idea. if there are 'n' functionalities and having
'n' controller drivers doesn't seem good in any direction.

Protocol driver can query the spi core about the bus topology and it is the
responsibility of the spi core and controller driver providing this information
to the upper layers.


Regards,
Punnaiah


>
> Assumption is GQSPI shall split to various platform_drivers (if each
> platform driver treated as a controller) thought it made up of  spi
> bus.
>
>>>
>>> Based on the above comments, there is an approach to handle this
>>> support and I'm not 100% sure whether this fits or not but we
>>> implemented the same -  this is "probing child devices from parent"
>>> (there was a discussion with Arnd earlier wrt this, but I'm unable to
>>> get the mailing thread)
>>>
>>> Added Arnd (probably will give more inputs or corrections)
>>>
>>> Let me explain how we implemented on our design.
>>> We have PCIe controller that support basic root complex handling, dma
>>> and controller hotplug (not in-build pcie hp) and ideally we need to
>>> write driver for handling root complex on drivers/pci/host and one
>>> hotplug driver in drivers/pci and one more driver in drivers/dma for
>>> handling pcie dma stuff. And some pcie calls need to navigate from
>>> root complex driver to dma and hotplug driver that means there is call
>>> transition from driver/pci to driver/dma which is absolutely not a
>>> good approach (spi to spi-nor and spi-nand transition - in GQSPI case)
>>>
>>> So the implementation we follow is like there is a pcie root complex
>>> driver(probably generic spi driver in drivers/spi/*) and inside probe
>>> we have register platform_device for hotplug (spi-nor) and dma
>>> (spi-nand) and the dma driver in drivers/dma and hotplug driver in
>>> driver/pci/ are platform drivers which is of legacy binding (not with
>>> dts) so there should be a common dts for root complex driver
>>> (drivers/spi/*) and individual child driver need to take those while
>>> registering platform_device.
>>>
>>> example pseudo:
>>>
>>> drivers/dma/dma-child2.c
>>>
>>> Legacy platform_driver binding and handling dma future as normal dma
>>> driver, spi-nand in your case
>>>
>>> drivers/pci/hotplug/hp-child1.c
>>>
>>> Legacy platform_driver binding and handling hotplug future as normal
>>> hotplug driver, spi-nor in your case.
>>>
>>> drivers/pci/host/rc-parent-pci.c
>>>
>>> static int rc_parent_pcie_probe_bridge(struct platform_device *pdev)
>>> {
>>>    // Generic rc handling (genric spi stuff)
>>>
>>>    // Hotplug handling (spi-nor)
>>>    - platform_device_alloc
>>>    - assign need resources
>>>    - register pdev using platform_device_add
>>>
>>>     // DMA handling (spi-nand)
>>>    - same as above
>>> }
>>>
>>> static const struct of_device_id rc_parent_pcie_match_table[] = {
>>>         {.compatible = "abc,rc-parent",},
>>>         {},
>>> };
>>>
>>> static struct platform_driver rc_parent_pcie_driver = {
>>>         .driver = {
>>>                    .name = "rc-parent",
>>>                    .of_match_table = of_match_ptr(rc_parent_pcie_match_table),
>>>         },
>>>         .probe = rc_parent_pcie_probe_bridge,
>>> };
>>> module_platform_driver(rc_parent_pcie_driver);
>>>
>>> I couldn't find any driver mainlined wrt this design, think more on
>>> GQSPI front, whether this design fits well or not.
>
> thanks!
> --
> Jagan | openedev.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Jagan Teki]

On 27 August 2015 at 17:19, punnaiah choudary kalluri
<punnaia@xilinx.com> wrote:
> On Thu, Aug 27, 2015 at 3:45 PM, Jagan Teki <jteki@openedev.com> wrote:
>> On 27 August 2015 at 14:18, punnaiah choudary kalluri
>> <punnaia@xilinx.com> wrote:
>>> On Thu, Aug 27, 2015 at 11:53 AM, Jagan Teki <jteki@openedev.com> wrote:
>>>> On 26 August 2015 at 21:02, punnaiah choudary kalluri
>>>> <punnaia@xilinx.com> wrote:
>>>>> On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki <jteki@openedev.com> wrote:
>>>>>> On 26 August 2015 at 11:56, Ranjit Waghmode <ranjit.waghmode@xilinx.com> wrote:
>>>>>>> This series adds dual parallel mode support for Zynq Ultrascale+
>>>>>>> MPSoC GQSPI controller driver.
>>>>>>>
>>>>>>> What is dual parallel mode?
>>>>>>> ---------------------------
>>>>>>> ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities:
>>>>>>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
>>>>>>> 2) Chip selects and clock are shared to both the flash devices
>>>>>>> 3) This mode is targeted for faster read/write speed and also doubles the size
>>>>>>> 4) Commands/data can be transmitted/received from both the devices(mirror),
>>>>>>>    or only upper or only lower flash memory devices.
>>>>>>> 5) Data arrangement:
>>>>>>>    With stripe enabled,
>>>>>>>    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>>>>>>>    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
>>> <snip>
>>>>>> I don't find any previous discussion about way to inform flash
>>>>>> dual-ness into spi-nor
>>>>>> from spi drivers.
>>>>>>
>>>>>> Here is my idea, probably others may think same.
>>>>>> Informing dual_flash from drivers/spi through flags or any other mode
>>>>>> bits is not a better approach as dual flash feature is specific to
>>>>>> spi-nor flash controller (controller specially designed for spi-nor
>>>>>> flash not the generic spi controller).  So if the driver sits on
>>>>>> drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash
>>>>>> specific things to spi-nor as it's not touching generic spi stack in
>>>>>> Linux. But there is a defined-drawback if the driver is moved to
>>>>>> drivers/mtd/spi-nor ie it can't use spi core API's at-all.
>>>>>
>>>>> Xilinx GQSPI is a generic quad spi controller. The primary goal is to support
>>>>> Generic/Future command sequences and Future NOR/NAND flash devices.
>>>>> This core can also be used for legacy SPI devices. Due to the generic nature
>>>>> of the core, software can generate any command sequence. It also has additional
>>>>> features like parallel and stacked configurations to double the data
>>>>> rate and size.
>>>>> Accessing spi-nor flash device is one particular use case and like
>>>>> that there will be
>>>>> many. So, we decided to keep this driver in generic spi framework and
>>>>> that is the ideal
>>>>> thing to do for the GQSPI controller.
>>>>
>>>> Yes, I understand the generic nature of the GQSPI and it's good to
>>>> have all-in-one like generic spi, spi-nor and spi-nand and more
>>>> together, but Linux stacks were implemented in such a way to support
>>>> the each type of controller with connected slaves separably for better
>>>> handling.
>>>
>>> True and this is the reason we have controller drivers and protocol drivers.
>>> GQSPI is the controller driver and spi-nor and spi-nand are the
>>> protocol drivers.
>>>
>>>>
>>>> Currently GQSPI driver is added in drivers/spi as it supports generic
>>>> spi nature and now it enhanced more through flags for supporting
>>>> spi-nor, what if we add spi-nand support for the same controller? do
>>>> we add one more driver in spi-nand framework (drivers/mtd/spi-nand -
>>>> an on going implementation)? My only observation here is even if the
>>>> controller is more generic to support more number of device classes,
>>>> and adding same driver and populate the slave stuff through flags or
>>>> different kind of mechanism to different driver stack, this is not a
>>>> better approach I thought.
>>>
>>> Just to clear, dual parallel( 2 CS and 8 IO lines) is not only specific
>>> to flash parts, one can use for any other custom streaming protocols
>>> I would say exporting dual parallel connection to protocol drivers is
>>> something like depicting the spi bus topology to the protocol layer.
>>
>> So dual parallel may not used for spi-nor flash it can also used other
>> spi slaves that's what your saying is it?
>
> Yes. As i said above, the main intention of this feature is to improve
> the data rate with an overhead of few IO lines.
>
>>
>>>
>>> AFAIK, spi-nor and spi-nand are protocol drivers for accessing the
>>> nor and nand flash devices sitting on the spi bus using the spi
>>> controller driver.
>>
>> Yes, I do agree with your point, but though driver stacks are
>> different with same kind of bus here, I'm trying to spit the GQSPI
>> into 3 different controller drivers as Linux understand it and fit on
>> to Linux stack with out disturbing the generic-ness.
>
>  I feel this is not a nice idea. if there are 'n' functionalities and having
> 'n' controller drivers doesn't seem good in any direction.

Sorry, to be clear It doesn't depend on n-theory instead it divergent
based on the how many Linux stacks that the GQSPI handle. And also I
commented earlier on thread that it may not be a better solutions but
it could be one of the good approach to fit into Linux-where-it's-not
touching core stacks.

Yes, we can do by adding spi bus driver and adding the
generic-ness,but I'm feel it ended up talking to many stacks which is
advisably not a good idea.

>
> Protocol driver can query the spi core about the bus topology and it is the
> responsibility of the spi core and controller driver providing this information
> to the upper layers.

I agreed the protocol driver definition here,as per the spi-nor
framework the drivers/mtd/spi-nor driver not only a protocol or slave
or flash drivers but there are some controller driver as well ex:
fsl-qspi-spi-nor.c

OK, we both are in different directions - lets wait for any more
comments from others.

>> Assumption is GQSPI shall split to various platform_drivers (if each
>> platform driver treated as a controller) thought it made up of  spi
>> bus.
>>
>>>>
>>>> Based on the above comments, there is an approach to handle this
>>>> support and I'm not 100% sure whether this fits or not but we
>>>> implemented the same -  this is "probing child devices from parent"
>>>> (there was a discussion with Arnd earlier wrt this, but I'm unable to
>>>> get the mailing thread)
>>>>
>>>> Added Arnd (probably will give more inputs or corrections)
>>>>
>>>> Let me explain how we implemented on our design.
>>>> We have PCIe controller that support basic root complex handling, dma
>>>> and controller hotplug (not in-build pcie hp) and ideally we need to
>>>> write driver for handling root complex on drivers/pci/host and one
>>>> hotplug driver in drivers/pci and one more driver in drivers/dma for
>>>> handling pcie dma stuff. And some pcie calls need to navigate from
>>>> root complex driver to dma and hotplug driver that means there is call
>>>> transition from driver/pci to driver/dma which is absolutely not a
>>>> good approach (spi to spi-nor and spi-nand transition - in GQSPI case)
>>>>
>>>> So the implementation we follow is like there is a pcie root complex
>>>> driver(probably generic spi driver in drivers/spi/*) and inside probe
>>>> we have register platform_device for hotplug (spi-nor) and dma
>>>> (spi-nand) and the dma driver in drivers/dma and hotplug driver in
>>>> driver/pci/ are platform drivers which is of legacy binding (not with
>>>> dts) so there should be a common dts for root complex driver
>>>> (drivers/spi/*) and individual child driver need to take those while
>>>> registering platform_device.
>>>>
>>>> example pseudo:
>>>>
>>>> drivers/dma/dma-child2.c
>>>>
>>>> Legacy platform_driver binding and handling dma future as normal dma
>>>> driver, spi-nand in your case
>>>>
>>>> drivers/pci/hotplug/hp-child1.c
>>>>
>>>> Legacy platform_driver binding and handling hotplug future as normal
>>>> hotplug driver, spi-nor in your case.
>>>>
>>>> drivers/pci/host/rc-parent-pci.c
>>>>
>>>> static int rc_parent_pcie_probe_bridge(struct platform_device *pdev)
>>>> {
>>>>    // Generic rc handling (genric spi stuff)
>>>>
>>>>    // Hotplug handling (spi-nor)
>>>>    - platform_device_alloc
>>>>    - assign need resources
>>>>    - register pdev using platform_device_add
>>>>
>>>>     // DMA handling (spi-nand)
>>>>    - same as above
>>>> }
>>>>
>>>> static const struct of_device_id rc_parent_pcie_match_table[] = {
>>>>         {.compatible = "abc,rc-parent",},
>>>>         {},
>>>> };
>>>>
>>>> static struct platform_driver rc_parent_pcie_driver = {
>>>>         .driver = {
>>>>                    .name = "rc-parent",
>>>>                    .of_match_table = of_match_ptr(rc_parent_pcie_match_table),
>>>>         },
>>>>         .probe = rc_parent_pcie_probe_bridge,
>>>> };
>>>> module_platform_driver(rc_parent_pcie_driver);
>>>>
>>>> I couldn't find any driver mainlined wrt this design, think more on
>>>> GQSPI front, whether this design fits well or not.

thanks!
-- 
Jagan | openedev.

RE: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Ranjit Abhimanyu Waghmode]

Hi Marek,

> -----Original Message-----
> From: Marek Vasut [mailto:marex-ynQEQJNshbs@public.gmane.org]
> Sent: Wednesday, August 26, 2015 12:26 PM
> To: Ranjit Abhimanyu Waghmode
> Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org; computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Michal Simek; Soren Brinkmann; zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org; b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org; knut.wohlrab-V5te9oGctAVWk0Htik3J/w@public.gmane.org;
> juhosg-p3rKhJxN3npAfugRpC6u6w@public.gmane.org; beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org; linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Harini Katakam; Punnaiah Choudary Kalluri
> Subject: Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq
> MPSoC GQSPI controller
> 
> On Wednesday, August 26, 2015 at 08:26:03 AM, Ranjit Waghmode wrote:
> > This series adds dual parallel mode support for Zynq Ultrascale+ MPSoC
> > GQSPI controller driver.
> >
> > What is dual parallel mode?
> > ---------------------------
> > ZynqMP GQSPI controller supports Dual Parallel mode with following
> > functionalities: 1) Supporting two SPI flash memories operating in
> > parallel. 8 I/O lines. 2) Chip selects and clock are shared to both
> > the flash devices
> > 3) This mode is targeted for faster read/write speed and also doubles
> > the size 4) Commands/data can be transmitted/received from both the
> > devices(mirror), or only upper or only lower flash memory devices.
> > 5) Data arrangement:
> >    With stripe enabled,
> >    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
> >    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
> 
> This might be a dumb question, but why don't you just treat this as an SPI NOR
> flash with 8-bit bus ?

In case of dual parallel configuration of this controller there are different modes like single, dual and quad mode.
Whatever you are suggesting would fit only in the case of Quad mode operation as both buses would have 4 lines each.
In case of single mode of parallel configuration, there would be two buses; but the line on each bus would one. So altogether there will be two lines.
And in case of dual mode of parallel configuration each bus will be having two lines. So altogether 4 lines will be there.
So keeping 8 lines would not support above two modes of parallel configuration correctly.

Logically it is a single flash with 8 IO lines but physically it's a two flash devices and each has 4 IO lines. 
So, in this case, read and write addresses should be always even and minimum data that can be accessed is 2 bytes.

Regards,
Ranjit

> 
> Best regards,
> Marek Vasut
--
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

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Marek Vasut]

On Wednesday, September 02, 2015 at 07:12:14 PM, Ranjit Abhimanyu Waghmode 
wrote:
> Hi Marek,
> 
> > -----Original Message-----
> > From: Marek Vasut [mailto:marex-ynQEQJNshbs@public.gmane.org]
> > Sent: Wednesday, August 26, 2015 12:26 PM
> > To: Ranjit Abhimanyu Waghmode
> > Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org; computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> > broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Michal Simek; Soren Brinkmann; zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> > ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org; b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org; knut.wohlrab-V5te9oGctAVWk0Htik3J/w@public.gmane.org;
> > juhosg-p3rKhJxN3npAfugRpC6u6w@public.gmane.org; beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org; linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> > linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> > kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Harini Katakam; Punnaiah Choudary Kalluri
> > Subject: Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in
> > Zynq MPSoC GQSPI controller
> > 
> > On Wednesday, August 26, 2015 at 08:26:03 AM, Ranjit Waghmode wrote:
> > > This series adds dual parallel mode support for Zynq Ultrascale+ MPSoC
> > > GQSPI controller driver.
> > > 
> > > What is dual parallel mode?
> > > ---------------------------
> > > ZynqMP GQSPI controller supports Dual Parallel mode with following
> > > functionalities: 1) Supporting two SPI flash memories operating in
> > > parallel. 8 I/O lines. 2) Chip selects and clock are shared to both
> > > the flash devices
> > > 3) This mode is targeted for faster read/write speed and also doubles
> > > the size 4) Commands/data can be transmitted/received from both the
> > > devices(mirror), or only upper or only lower flash memory devices.
> > > 
> > > 5) Data arrangement:
> > >    With stripe enabled,
> > >    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
> > >    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
> > 
> > This might be a dumb question, but why don't you just treat this as an
> > SPI NOR flash with 8-bit bus ?
> 
> In case of dual parallel configuration of this controller there are
> different modes like single, dual and quad mode. Whatever you are
> suggesting would fit only in the case of Quad mode operation as both buses
> would have 4 lines each. In case of single mode of parallel configuration,
> there would be two buses; but the line on each bus would one. So
> altogether there will be two lines. And in case of dual mode of parallel
> configuration each bus will be having two lines. So altogether 4 lines
> will be there. So keeping 8 lines would not support above two modes of
> parallel configuration correctly.
> 
> Logically it is a single flash with 8 IO lines but physically it's a two
> flash devices and each has 4 IO lines. So, in this case, read and write
> addresses should be always even and minimum data that can be accessed is 2
> bytes.

Oh, I see what the issue is now. It has to do with configuring the flash
into correct bus-width mode, right ?

Best regards,
Marek Vasut
--
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

Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe

[Mark Brown]

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

On Wed, Aug 26, 2015 at 11:56:04AM +0530, Ranjit Waghmode wrote:

> To support dual parallel mode operation of ZynqMP GQSPI controller
> following API's are added inside the core:

As covered in SubmittingPatches please try to make each patch a single
change rather than having multiple separate changes in one commit.

> +	/* Controller may support more than one chip.
> +	 * This flag will enable that feature.
> +	 */
> +#define SPI_MASTER_BOTH_CS		BIT(8)		/* enable both chips */

This isn't saying that the controller supports more than one chip, it's
saying that the controller supports asserting more than one chip select
at once which isn't the same thing.  I'm also not entirely sure that
this makes sense as a separate feature to the data striping one - I'm
struggling to think of a way to use this sensibly separately to that.

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

RE: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Ranjit Abhimanyu Waghmode]

Hi,

> -----Original Message-----
> From: Marek Vasut [mailto:marex-ynQEQJNshbs@public.gmane.org]
> Sent: Thursday, September 03, 2015 12:26 AM
> To: Ranjit Abhimanyu Waghmode
> Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org; computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Michal Simek; Soren Brinkmann; zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org; b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org; knut.wohlrab-V5te9oGctAVWk0Htik3J/w@public.gmane.org;
> juhosg-p3rKhJxN3npAfugRpC6u6w@public.gmane.org; beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org; linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Harini Katakam; Punnaiah Choudary Kalluri
> Subject: Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq
> MPSoC GQSPI controller
> 
> On Wednesday, September 02, 2015 at 07:12:14 PM, Ranjit Abhimanyu
> Waghmode
> wrote:
> > Hi Marek,
> >
> > > -----Original Message-----
> > > From: Marek Vasut [mailto:marex-ynQEQJNshbs@public.gmane.org]
> > > Sent: Wednesday, August 26, 2015 12:26 PM
> > > To: Ranjit Abhimanyu Waghmode
> > > Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org; computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> > > broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Michal Simek; Soren Brinkmann; zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> > > ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org; b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org;
> > > knut.wohlrab-V5te9oGctAVWk0Htik3J/w@public.gmane.org; juhosg-p3rKhJxN3npAfugRpC6u6w@public.gmane.org;
> beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org;
> > > linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm- kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> > > Harini Katakam; Punnaiah Choudary Kalluri
> > > Subject: Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support
> > > in Zynq MPSoC GQSPI controller
> > >
> > > On Wednesday, August 26, 2015 at 08:26:03 AM, Ranjit Waghmode wrote:
> > > > This series adds dual parallel mode support for Zynq Ultrascale+
> > > > MPSoC GQSPI controller driver.
> > > >
> > > > What is dual parallel mode?
> > > > ---------------------------
> > > > ZynqMP GQSPI controller supports Dual Parallel mode with following
> > > > functionalities: 1) Supporting two SPI flash memories operating in
> > > > parallel. 8 I/O lines. 2) Chip selects and clock are shared to
> > > > both the flash devices
> > > > 3) This mode is targeted for faster read/write speed and also
> > > > doubles the size 4) Commands/data can be transmitted/received from
> > > > both the devices(mirror), or only upper or only lower flash memory
> devices.
> > > >
> > > > 5) Data arrangement:
> > > >    With stripe enabled,
> > > >    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
> > > >    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
> > >
> > > This might be a dumb question, but why don't you just treat this as
> > > an SPI NOR flash with 8-bit bus ?
> >
> > In case of dual parallel configuration of this controller there are
> > different modes like single, dual and quad mode. Whatever you are
> > suggesting would fit only in the case of Quad mode operation as both
> > buses would have 4 lines each. In case of single mode of parallel
> > configuration, there would be two buses; but the line on each bus
> > would one. So altogether there will be two lines. And in case of dual
> > mode of parallel configuration each bus will be having two lines. So
> > altogether 4 lines will be there. So keeping 8 lines would not support
> > above two modes of parallel configuration correctly.
> >
> > Logically it is a single flash with 8 IO lines but physically it's a
> > two flash devices and each has 4 IO lines. So, in this case, read and
> > write addresses should be always even and minimum data that can be
> > accessed is 2 bytes.
> 
> Oh, I see what the issue is now. It has to do with configuring the flash into
> correct bus-width mode, right ?
Yes.
> 
> Best regards,
> Marek Vasut
--
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

Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller

[Marek Vasut]

On Thursday, September 03, 2015 at 03:25:00 PM, Ranjit Abhimanyu Waghmode wrote:
> Hi,
> 
> > -----Original Message-----
> > From: Marek Vasut [mailto:marex-ynQEQJNshbs@public.gmane.org]
> > Sent: Thursday, September 03, 2015 12:26 AM
> > To: Ranjit Abhimanyu Waghmode
> > Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org; computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> > broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Michal Simek; Soren Brinkmann; zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> > ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org; b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org; knut.wohlrab-V5te9oGctAVWk0Htik3J/w@public.gmane.org;
> > juhosg-p3rKhJxN3npAfugRpC6u6w@public.gmane.org; beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org; linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> > linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> > kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Harini Katakam; Punnaiah Choudary Kalluri
> > Subject: Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in
> > Zynq MPSoC GQSPI controller
> > 
> > On Wednesday, September 02, 2015 at 07:12:14 PM, Ranjit Abhimanyu
> > Waghmode
> > 
> > wrote:
> > > Hi Marek,
> > > 
> > > > -----Original Message-----
> > > > From: Marek Vasut [mailto:marex-ynQEQJNshbs@public.gmane.org]
> > > > Sent: Wednesday, August 26, 2015 12:26 PM
> > > > To: Ranjit Abhimanyu Waghmode
> > > > Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org; computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> > > > broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Michal Simek; Soren Brinkmann; zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> > > > ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org; b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org;
> > > > knut.wohlrab-V5te9oGctAVWk0Htik3J/w@public.gmane.org; juhosg-p3rKhJxN3npAfugRpC6u6w@public.gmane.org;
> > 
> > beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org;
> > 
> > > > linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > > linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm- kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> > > > Harini Katakam; Punnaiah Choudary Kalluri
> > > > Subject: Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support
> > > > in Zynq MPSoC GQSPI controller
> > > > 
> > > > On Wednesday, August 26, 2015 at 08:26:03 AM, Ranjit Waghmode wrote:
> > > > > This series adds dual parallel mode support for Zynq Ultrascale+
> > > > > MPSoC GQSPI controller driver.
> > > > > 
> > > > > What is dual parallel mode?
> > > > > ---------------------------
> > > > > ZynqMP GQSPI controller supports Dual Parallel mode with following
> > > > > functionalities: 1) Supporting two SPI flash memories operating in
> > > > > parallel. 8 I/O lines. 2) Chip selects and clock are shared to
> > > > > both the flash devices
> > > > > 3) This mode is targeted for faster read/write speed and also
> > > > > doubles the size 4) Commands/data can be transmitted/received from
> > > > > both the devices(mirror), or only upper or only lower flash memory
> > 
> > devices.
> > 
> > > > > 5) Data arrangement:
> > > > >    With stripe enabled,
> > > > >    Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
> > > > >    Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
> > > > 
> > > > This might be a dumb question, but why don't you just treat this as
> > > > an SPI NOR flash with 8-bit bus ?
> > > 
> > > In case of dual parallel configuration of this controller there are
> > > different modes like single, dual and quad mode. Whatever you are
> > > suggesting would fit only in the case of Quad mode operation as both
> > > buses would have 4 lines each. In case of single mode of parallel
> > > configuration, there would be two buses; but the line on each bus
> > > would one. So altogether there will be two lines. And in case of dual
> > > mode of parallel configuration each bus will be having two lines. So
> > > altogether 4 lines will be there. So keeping 8 lines would not support
> > > above two modes of parallel configuration correctly.
> > > 
> > > Logically it is a single flash with 8 IO lines but physically it's a
> > > two flash devices and each has 4 IO lines. So, in this case, read and
> > > write addresses should be always even and minimum data that can be
> > > accessed is 2 bytes.
> > 
> > Oh, I see what the issue is now. It has to do with configuring the flash
> > into correct bus-width mode, right ?
> 
> Yes.

Thanks!
--
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

RE: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe

[Ranjit Abhimanyu Waghmode]

Hi Mark,

> -----Original Message-----
> From: Mark Brown [mailto:broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Thursday, September 03, 2015 5:43 PM
> To: Ranjit Abhimanyu Waghmode
> Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org; computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; Michal Simek;
> Soren Brinkmann; zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org; marex-ynQEQJNshbs@public.gmane.org;
> b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org; knut.wohlrab-V5te9oGctAVWk0Htik3J/w@public.gmane.org; juhosg-p3rKhJxN3npAfugRpC6u6w@public.gmane.org;
> beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org; linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Harini Katakam; Punnaiah Choudary Kalluri
> Subject: Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data
> stripe
> 
> On Wed, Aug 26, 2015 at 11:56:04AM +0530, Ranjit Waghmode wrote:
> 
> > To support dual parallel mode operation of ZynqMP GQSPI controller
> > following API's are added inside the core:
> 
> As covered in SubmittingPatches please try to make each patch a single change
> rather than having multiple separate changes in one commit.
I will split the patch.
> 
> > +	/* Controller may support more than one chip.
> > +	 * This flag will enable that feature.
> > +	 */
> > +#define SPI_MASTER_BOTH_CS		BIT(8)		/* enable both
> chips */
> 
> This isn't saying that the controller supports more than one chip, it's saying that
> the controller supports asserting more than one chip select at once which isn't
> the same thing.  I'm also not entirely sure that this makes sense as a separate
> feature to the data striping one - I'm struggling to think of a way to use this
> sensibly separately to that.
If the SPI controller is having more than one chip select and the data lines are distributed equally.
And also there is requirement to activate all the chip selects in one go.

Now we can consider following use cases:

Suppose we need to send the same data to multiple slaves of same kind:
Here the application need not to do individual slave access for writing, instead it can send data to all the devices in one go.

Let's take another case where application is trying to send data in such a way that first nibble of the byte will got to the one slave and the second nibble of the byte will go to the other slave:
Here data in slave devices can be organized by taking advantage of above topology along with the support in hardware.

Regards,
Ranjit
--
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

Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe

[Martin Sperl]

> On 03.09.2015, at 14:12, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> 
> On Wed, Aug 26, 2015 at 11:56:04AM +0530, Ranjit Waghmode wrote:
> 
>> To support dual parallel mode operation of ZynqMP GQSPI controller
>> following API's are added inside the core:
> 
> As covered in SubmittingPatches please try to make each patch a single
> change rather than having multiple separate changes in one commit.
> 
>> +	/* Controller may support more than one chip.
>> +	 * This flag will enable that feature.
>> +	 */
>> +#define SPI_MASTER_BOTH_CS		BIT(8)		/* enable both chips */
> 
> This isn't saying that the controller supports more than one chip, it's
> saying that the controller supports asserting more than one chip select
> at once which isn't the same thing.  I'm also not entirely sure that
> this makes sense as a separate feature to the data striping one - I'm
> struggling to think of a way to use this sensibly separately to that.

Well - there is one use-case that I can think of:
fbtft has the requirement for some devices to control a GPIO to
differentiate between command and data getting transferred
- sort of 9 bit.

Right now it is done outside of spi in the fbtft driver itself wrapping
spi_sync().

Similarly a “hold” line on an eeprom or similar could get (de)asserted
without requiring holding a spi-bus-lock.

But then the current patch would not allow this kind of “generic”
use-case.

Martin


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

Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe

[Mark Brown]

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

On Fri, Sep 04, 2015 at 02:35:52PM +0200, Martin Sperl wrote:
> > On 03.09.2015, at 14:12, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

> > This isn't saying that the controller supports more than one chip, it's
> > saying that the controller supports asserting more than one chip select
> > at once which isn't the same thing.  I'm also not entirely sure that
> > this makes sense as a separate feature to the data striping one - I'm
> > struggling to think of a way to use this sensibly separately to that.

> Well - there is one use-case that I can think of:
> fbtft has the requirement for some devices to control a GPIO to
> differentiate between command and data getting transferred
> - sort of 9 bit.

That's another thing again, isn't it?  It's one device switching between
two different control interfaces at runtime rather than two devices
controlled in lockstep.

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

Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe

[Martin Sperl]

> On 04.09.2015, at 17:37, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> 
> On Fri, Sep 04, 2015 at 02:35:52PM +0200, Martin Sperl wrote:
>>> On 03.09.2015, at 14:12, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> 
>>> This isn't saying that the controller supports more than one chip, it's
>>> saying that the controller supports asserting more than one chip select
>>> at once which isn't the same thing.  I'm also not entirely sure that
>>> this makes sense as a separate feature to the data striping one - I'm
>>> struggling to think of a way to use this sensibly separately to that.
> 
>> Well - there is one use-case that I can think of:
>> fbtft has the requirement for some devices to control a GPIO to
>> differentiate between command and data getting transferred
>> - sort of 9 bit.
> 
> That's another thing again, isn't it?  It's one device switching between
> two different control interfaces at runtime rather than two devices
> controlled in lockstep.

I agree, but there may be a solution that can handle both, so I wanted
to mention it.
--
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

Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe

[Mark Brown]

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

On Fri, Sep 04, 2015 at 12:02:21PM +0000, Ranjit Abhimanyu Waghmode wrote:

Please fix your mail client to word wrap within paragraphs and to quote
text without reflowing it - your messages are very hard to read.

> > > +	/* Controller may support more than one chip.
> > > +	 * This flag will enable that feature.
> > > +	 */
> > > +#define SPI_MASTER_BOTH_CS		BIT(8)		/* enable both
> > chips */

> > This isn't saying that the controller supports more than one chip, it's saying that
> > the controller supports asserting more than one chip select at once which isn't
> > the same thing.  I'm also not entirely sure that this makes sense as a separate
> > feature to the data striping one - I'm struggling to think of a way to use this
> > sensibly separately to that.

> If the SPI controller is having more than one chip select and the data lines are distributed equally.
> And also there is requirement to activate all the chip selects in one go.

I'm not sure I understand the above, sorry.  At least not in so far as
how it relates to my concerns, especially the fact that the comment says
this enables support for more than one chip which is obviously a basic
SPI feature.

> Now we can consider following use cases:

> Suppose we need to send the same data to multiple slaves of same kind:
> Here the application need not to do individual slave access for writing, instead it can send data to all the devices in one go.

That's a *very* specific application which will only work for write only
devices - I'd be surprised if such systems actually had distinct chip
select lines at the CPU level.

> Let's take another case where application is trying to send data in such a way that first nibble of the byte will got to the one slave and the second nibble of the byte will go to the other slave:
> Here data in slave devices can be organized by taking advantage of above topology along with the support in hardware.

But do such devices actually exist?  I can imagine systems that might be
able to do that but I'd be very surprised to see anyone practically
designing them, they're going to be quite hard to use.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

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

Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe

[Harini Katakam]

Hi Mark,

On Fri, Sep 11, 2015 at 6:06 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Sep 04, 2015 at 12:02:21PM +0000, Ranjit Abhimanyu Waghmode wrote:
>
> Please fix your mail client to word wrap within paragraphs and to quote
> text without reflowing it - your messages are very hard to read.
>
>> > > + /* Controller may support more than one chip.
>> > > +  * This flag will enable that feature.
>> > > +  */
>> > > +#define SPI_MASTER_BOTH_CS               BIT(8)          /* enable both
>> > chips */
>
>> Now we can consider following use cases:
>
>> Suppose we need to send the same data to multiple slaves of same kind:
>> Here the application need not to do individual slave access for writing, instead it can send data to all the devices in one go.
>
> That's a *very* specific application which will only work for write only
> devices - I'd be surprised if such systems actually had distinct chip
> select lines at the CPU level.
>

Agreed that it is very specific but here are a few ways it is used
when communicating with two flash devices in parallel configuration:
- Write enable is sent to both devices using a single operation.
- Writing to any configuration registers in the flash is done in one go
- Some application that want to mirror important data to both devices.
Even with reading, the assertion of multiple cs combined with stripe
will mean:
- Two status bytes, one form each will be obtained in one operation
- Similarly data that was written using stripe is read back and combined.

Such systems could still maintain separate chip selects to perform
individual operations such as reading flash ID, debugging failures or
locking specific sectors.

Regards,
Harini
--
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