spi: zynqmp_qspi: Add support for ZynqMP qspi driver

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

Signed-off-by Siva Durga Prasad Paladugu <[email protected]>

---
 arch/arm/cpu/armv8/zynqmp/Kconfig |   7 +
 drivers/spi/Makefile              |   1 +
 drivers/spi/zynqmp_qspi.c         | 817

++++++++++++++++++++++++++++++++++++++ 3 files changed, 825 insertions(+) create mode 100644 drivers/spi/zynqmp_qspi.c

(quoted diff) +0 -0

b/arch/arm/cpu/armv8/zynqmp/Kconfig index 5ffc9f6..278248a 100644

arch/arm/cpu/armv8/zynqmp/Kconfig +0 -0

@@ -50,6 +50,13 @@ config BOOT_INIT_FILE
 	  Add register writes to boot.bin format (max 256 pairs).
 	  Expect a table of register-value pairs, e.g. "0x12345678

0x4321"

arch/arm/cpu/armv8/zynqmp/Kconfig +5 -0

+config ZYNQMP_QSPI
+	bool "Configure ZynqMP QSPI"
+	select DM_SPI
+	help
+	  This option is used to enable ZynqMP QSPI controller

driver which

arch/arm/cpu/armv8/zynqmp/Kconfig +2 -0

+	  is used to communicate with qspi flash devices.
+
 config ZYNQMP_USB
 	bool "Configure ZynqMP USB"

drivers/spi/Makefile +1 -0

index ad56203..b465c71 100644
@@ -50,3 +50,4 @@ obj-$(CONFIG_TI_QSPI) += ti_qspi.o
 obj-$(CONFIG_XILINX_SPI) += xilinx_spi.o
 obj-$(CONFIG_ZYNQ_SPI) += zynq_spi.o
 obj-$(CONFIG_ZYNQ_QSPI) += zynq_qspi.o
+obj-$(CONFIG_ZYNQMP_QSPI) += zynqmp_qspi.o

drivers/spi/zynqmp_qspi.c new file +38 -0

new file mode 100644
index 0000000..7ec669e
@@ -0,0 +1,817 @@
+/*
+ * (C) Copyright 2014 - 2015 Xilinx
+ *
+ * Xilinx ZynqMP Quad-SPI(QSPI) controller driver (master mode only)
+ *
+ * SPDX-License-Identifier:	GPL-2.0
+ */
+
+#include <common.h>
+#include <malloc.h>
+#include <memalign.h>
+#include <ubi_uboot.h>
+#include <spi.h>
+#include <spi_flash.h>
+#include <asm/io.h>
+#include <asm/arch/hardware.h>
+#include <asm/arch/sys_proto.h>
+#include <asm/arch/clk.h>
+#include "../mtd/spi/sf_internal.h"
+#include <clk.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define ZYNQMP_QSPI_GFIFO_STRT_MODE_MASK	BIT(29)
+#define ZYNQMP_QSPI_CONFIG_MODE_EN_MASK	(3 << 30)
+#define ZYNQMP_QSPI_CONFIG_DMA_MODE	(2 << 30)
+#define ZYNQMP_QSPI_CONFIG_CPHA_MASK	BIT(2)
+#define ZYNQMP_QSPI_CONFIG_CPOL_MASK	BIT(1)
+
+/* QSPI MIO's count for different connection topologies */
+#define ZYNQMP_QSPI_MIO_NUM_QSPI0		6
+#define ZYNQMP_QSPI_MIO_NUM_QSPI1		5
+#define ZYNQMP_QSPI_MIO_NUM_QSPI1_CS	1
+
+/*
+ * QSPI Interrupt Registers bit Masks
+ *
+ * All the four interrupt registers (Status/Mask/Enable/Disable)

have the same
+ * bit definitions.
+ */
+#define ZYNQMP_QSPI_IXR_TXNFULL_MASK 0x00000004 /* QSPI TX
FIFO Overflow */ +#define ZYNQMP_QSPI_IXR_TXFULL_MASK 0x00000008 /* QSPI TX FIFO is full */ +#define
ZYNQMP_QSPI_IXR_RXNEMTY_MASK 0x00000010 /* QSPI RX FIFO Not
Empty */ +#define ZYNQMP_QSPI_IXR_GFEMTY_MASK 0x00000080 /*
QSPI Generic FIFO Empty */ +#define ZYNQMP_QSPI_IXR_ALL_MASK (ZYNQMP_QSPI_IXR_TXNFULL_MASK | \

drivers/spi/zynqmp_qspi.c new file +8 -0

+					ZYNQMP_QSPI_IXR_RXNEMTY_MASK)
+
+/*
+ * QSPI Enable Register bit Masks
+ *
+ * This register is used to enable or disable the QSPI controller
+ */
+#define ZYNQMP_QSPI_ENABLE_ENABLE_MASK	0x00000001 /* QSPI

Enable Bit Mask */ +

drivers/spi/zynqmp_qspi.c new file +101 -0

+#define ZYNQMP_QSPI_GFIFO_LOW_BUS		BIT(14)
+#define ZYNQMP_QSPI_GFIFO_CS_LOWER	BIT(12)
+#define ZYNQMP_QSPI_GFIFO_UP_BUS		BIT(15)
+#define ZYNQMP_QSPI_GFIFO_CS_UPPER	BIT(13)
+#define ZYNQMP_QSPI_SPI_MODE_QSPI		(3 << 10)
+#define ZYNQMP_QSPI_SPI_MODE_SPI		BIT(10)
+#define ZYNQMP_QSPI_SPI_MODE_DUAL_SPI		(2 << 10)
+#define ZYNQMP_QSPI_IMD_DATA_CS_ASSERT	5
+#define ZYNQMP_QSPI_IMD_DATA_CS_DEASSERT	5
+#define ZYNQMP_QSPI_GFIFO_TX		BIT(16)
+#define ZYNQMP_QSPI_GFIFO_RX		BIT(17)
+#define ZYNQMP_QSPI_GFIFO_STRIPE_MASK	BIT(18)
+#define ZYNQMP_QSPI_GFIFO_IMD_MASK	0xFF
+#define ZYNQMP_QSPI_GFIFO_EXP_MASK	BIT(9)
+#define ZYNQMP_QSPI_GFIFO_DATA_XFR_MASK	BIT(8)
+#define ZYNQMP_QSPI_STRT_GEN_FIFO		BIT(28)
+#define ZYNQMP_QSPI_GEN_FIFO_STRT_MOD	BIT(29)
+#define ZYNQMP_QSPI_GFIFO_WP_HOLD		BIT(19)
+#define ZYNQMP_QSPI_BAUD_DIV_MASK	(7 << 3)
+#define ZYNQMP_QSPI_DFLT_BAUD_RATE_DIV	BIT(3)
+#define ZYNQMP_QSPI_GFIFO_ALL_INT_MASK	0xFBE
+#define ZYNQMP_QSPI_DMA_DST_I_STS_DONE	BIT(1)
+#define ZYNQMP_QSPI_DMA_DST_I_STS_MASK	0xFE
+#define MODEBITS	0x6
+
+#define QUAD_OUT_READ_CMD		0x6B
+#define QUAD_PAGE_PROGRAM_CMD		0x32
+#define DUAL_OUTPUT_FASTRD_CMD		0x3B
+
+#define ZYNQMP_QSPI_GFIFO_SELECT		BIT(0)
+
+#define ZYNQMP_QSPI_FIFO_THRESHOLD 1
+
+#define SPI_XFER_ON_BOTH	0
+#define SPI_XFER_ON_LOWER	1
+#define SPI_XFER_ON_UPPER	2
+
+#define ZYNQMP_QSPI_DMA_ALIGN	0x4
+#define ZYNQMP_QSPI_MAX_BAUD_RATE_VAL	7
+#define ZYNQMP_QSPI_DFLT_BAUD_RATE_VAL	2
+
+#define ZYNQMP_QSPI_TIMEOUT	100000000
+
+/* QSPI register offsets */
+struct zynqmp_qspi_regs {
+	u32 confr;	/* 0x00 */
+	u32 isr;	/* 0x04 */
+	u32 ier;	/* 0x08 */
+	u32 idisr;	/* 0x0C */
+	u32 imaskr;	/* 0x10 */
+	u32 enbr;	/* 0x14 */
+	u32 dr;		/* 0x18 */
+	u32 txd0r;	/* 0x1C */
+	u32 drxr;	/* 0x20 */
+	u32 sicr;	/* 0x24 */
+	u32 txftr;	/* 0x28 */
+	u32 rxftr;	/* 0x2C */
+	u32 gpior;	/* 0x30 */
+	u32 reserved0;	/* 0x34 */
+	u32 lpbkdly;	/* 0x38 */
+	u32 reserved1;	/* 0x3C */
+	u32 genfifo;	/* 0x40 */
+	u32 gqspisel;	/* 0x44 */
+	u32 reserved2;	/* 0x48 */
+	u32 gqfifoctrl;	/* 0x4C */
+	u32 gqfthr;	/* 0x50 */
+	u32 gqpollcfg;	/* 0x54 */
+	u32 gqpollto;	/* 0x58 */
+	u32 gqxfersts;	/* 0x5C */
+	u32 gqfifosnap;	/* 0x60 */
+	u32 gqrxcpy;	/* 0x64 */
+	u32 reserved3[36];	/* 0x68 */
+	u32 gqspidlyadj;	/* 0xF8 */
+};
+
+struct zynqmp_qspi_dma_regs {
+	u32 dmadst;	/* 0x00 */
+	u32 dmasize;	/* 0x04 */
+	u32 dmasts;	/* 0x08 */
+	u32 dmactrl;	/* 0x0C */
+	u32 reserved0;	/* 0x10 */
+	u32 dmaisr;	/* 0x14 */
+	u32 dmaier;	/* 0x18 */
+	u32 dmaidr;	/* 0x1C */
+	u32 dmaimr;	/* 0x20 */
+	u32 dmactrl2;	/* 0x24 */
+	u32 dmadstmsb;	/* 0x28 */
+};
+
+struct zynqmp_qspi_platdata {
+	struct zynqmp_qspi_regs *regs;
+	struct zynqmp_qspi_dma_regs *dma_regs;
+	u32 frequency;
+	u32 speed_hz;
+	unsigned int tx_rx_mode;
+};
+
+struct zynqmp_qspi_priv {
+	struct zynqmp_qspi_regs *regs;
+	struct zynqmp_qspi_dma_regs *dma_regs;
+	u8 mode;

drivers/spi/zynqmp_qspi.c new file +13 -0

+
+static int zynqmp_qspi_ofdata_to_platdata(struct udevice *bus)
+{
+	struct zynqmp_qspi_platdata *plat = bus->platdata;
+	u32 mode = 0;
+	u32 value;
+	int ret;
+	struct clk clk;
+	unsigned long clock;
+
+	debug("%s\n", __func__);
+
+	plat->regs = (struct zynqmp_qspi_regs

*)(devfdt_get_addr(bus) + 0x100);

drivers/spi/zynqmp_qspi.c new file +1 -0

+	plat->dma_regs = (struct zynqmp_qspi_dma_regs

*)(devfdt_get_addr(bus) +

drivers/spi/zynqmp_qspi.c new file +104 -0

+
+	ret = clk_get_by_index(bus, 0, &clk);
+	if (ret < 0) {
+		dev_err(dev, "failed to get clock\n");
+		return ret;
+	}
+
+	clock = clk_get_rate(&clk);
+	if (IS_ERR_VALUE(clock)) {
+		dev_err(dev, "failed to get rate\n");
+		return clock;
+	}
+	debug("%s: CLK %ld\n", __func__, clock);
+
+	ret = clk_enable(&clk);
+	if (ret && ret != -ENOSYS) {
+		dev_err(dev, "failed to enable clock\n");
+		return ret;
+	}
+
+	value = dev_read_u32_default(bus, "spi-rx-bus-width", 1);
+	switch (value) {
+	case 1:
+		break;
+	case 2:
+		mode |= SPI_RX_DUAL;
+		break;
+	case 4:
+		mode |= SPI_RX_QUAD;
+		break;
+	default:
+		printf("Invalid spi-rx-bus-width %d\n", value);
+		break;
+	}
+
+	value = dev_read_u32_default(bus, "spi-tx-bus-width", 1);
+	switch (value) {
+	case 1:
+		break;
+	case 2:
+		mode |= SPI_TX_DUAL;
+		break;
+	case 4:
+		mode |= SPI_TX_QUAD;
+		break;
+	default:
+		printf("Invalid spi-tx-bus-width %d\n", value);
+		break;
+	}
+
+	plat->tx_rx_mode = mode;
+
+	plat->frequency = clock;
+	plat->speed_hz = plat->frequency;
+
+	return 0;
+}
+
+static void zynqmp_qspi_init_hw(struct zynqmp_qspi_priv *priv)
+{
+	u32 config_reg;
+	struct zynqmp_qspi_regs *regs = priv->regs;
+
+	writel(ZYNQMP_QSPI_GFIFO_SELECT, &regs->gqspisel);
+	writel(ZYNQMP_QSPI_GFIFO_ALL_INT_MASK, &regs->idisr);
+	writel(ZYNQMP_QSPI_FIFO_THRESHOLD, &regs->txftr);
+	writel(ZYNQMP_QSPI_FIFO_THRESHOLD, &regs->rxftr);
+	writel(ZYNQMP_QSPI_GFIFO_ALL_INT_MASK, &regs->isr);
+
+	config_reg = readl(&regs->confr);
+	config_reg &= ~(ZYNQMP_QSPI_GFIFO_STRT_MODE_MASK |
+			ZYNQMP_QSPI_CONFIG_MODE_EN_MASK);
+	config_reg |= ZYNQMP_QSPI_CONFIG_DMA_MODE |
+		      ZYNQMP_QSPI_GFIFO_WP_HOLD |
+		      ZYNQMP_QSPI_DFLT_BAUD_RATE_DIV;
+	writel(config_reg, &regs->confr);
+
+	writel(ZYNQMP_QSPI_ENABLE_ENABLE_MASK, &regs->enbr);
+}
+
+static u32 zynqmp_qspi_bus_select(struct zynqmp_qspi_priv *priv)
+{
+	u32 gqspi_fifo_reg = 0;
+
+	gqspi_fifo_reg = ZYNQMP_QSPI_GFIFO_LOW_BUS |
+			 ZYNQMP_QSPI_GFIFO_CS_LOWER;
+
+	return gqspi_fifo_reg;
+}
+
+static void zynqmp_qspi_fill_gen_fifo(struct zynqmp_qspi_priv *priv,
+				      u32 gqspi_fifo_reg)
+{
+	struct zynqmp_qspi_regs *regs = priv->regs;
+	u32 reg;
+
+	do {
+		reg = readl(&regs->isr);
+	} while (!(reg & ZYNQMP_QSPI_IXR_GFEMTY_MASK));
+
+	writel(gqspi_fifo_reg, &regs->genfifo);
+}
+
+static void zynqmp_qspi_chipselect(struct zynqmp_qspi_priv *priv,

int is_on) +{

drivers/spi/zynqmp_qspi.c new file +25 -0

+	u32 gqspi_fifo_reg = 0;
+
+	if (is_on) {
+		gqspi_fifo_reg = zynqmp_qspi_bus_select(priv);
+		gqspi_fifo_reg |= ZYNQMP_QSPI_SPI_MODE_SPI |
+				  ZYNQMP_QSPI_IMD_DATA_CS_ASSERT;
+	} else {
+		gqspi_fifo_reg = ZYNQMP_QSPI_GFIFO_LOW_BUS;
+		gqspi_fifo_reg |= ZYNQMP_QSPI_IMD_DATA_CS_DEASSERT;
+	}
+
+	debug("GFIFO_CMD_CS: 0x%x\n", gqspi_fifo_reg);
+
+	zynqmp_qspi_fill_gen_fifo(priv, gqspi_fifo_reg);
+}
+
+#define GQSPI_BAUD_DIV_SHIFT		2
+#define GQSPI_LPBK_DLY_ADJ_LPBK_SHIFT	5
+#define GQSPI_LPBK_DLY_ADJ_DLY_1	0x2
+#define GQSPI_LPBK_DLY_ADJ_DLY_1_SHIFT	3
+#define GQSPI_LPBK_DLY_ADJ_DLY_0	0x3
+#define GQSPI_USE_DATA_DLY		0x1
+#define GQSPI_USE_DATA_DLY_SHIFT	31
+#define GQSPI_DATA_DLY_ADJ_VALUE	0x2
+#define GQSPI_DATA_DLY_ADJ_SHIFT	28

drivers/spi/zynqmp_qspi.c new file +6 -0

+void zynqmp_qspi_set_tapdelay(struct udevice *bus, u32 baudrateval)
+{
+	struct zynqmp_qspi_platdata *plat = bus->platdata;
+	struct zynqmp_qspi_priv *priv = dev_get_priv(bus);
+	struct zynqmp_qspi_regs *regs = priv->regs;
+	u32 tapdlybypass = 0, lpbkdlyadj = 0, datadlyadj = 0,

clk_rate;

drivers/spi/zynqmp_qspi.c new file +10 -0

+	u32 reqhz = 0;
+
+	clk_rate = plat->frequency;
+	reqhz = (clk_rate / (GQSPI_BAUD_DIV_SHIFT << baudrateval));
+
+	debug("%s, req_hz:%d, clk_rate:%d, baudrateval:%d\n",
+	      __func__, reqhz, clk_rate, baudrateval);
+
+	if (reqhz < GQSPI_FREQ_40MHZ) {
+		zynqmp_mmio_read(IOU_TAPDLY_BYPASS_OFST,

&tapdlybypass);

drivers/spi/zynqmp_qspi.c new file +4 -0

+		tapdlybypass |= (TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
+				TAP_DLY_BYPASS_LQSPI_RX_SHIFT);
+	} else if (reqhz < GQSPI_FREQ_100MHZ) {
+		zynqmp_mmio_read(IOU_TAPDLY_BYPASS_OFST,

&tapdlybypass);

drivers/spi/zynqmp_qspi.c new file +6 -0

+		tapdlybypass |= (TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
+				TAP_DLY_BYPASS_LQSPI_RX_SHIFT);
+		lpbkdlyadj = readl(&regs->lpbkdly);
+		lpbkdlyadj |= (GQSPI_LPBK_DLY_ADJ_USE_LPBK_MASK);
+		datadlyadj = readl(&regs->gqspidlyadj);
+		datadlyadj |= ((GQSPI_USE_DATA_DLY <<

GQSPI_USE_DATA_DLY_SHIFT)

drivers/spi/zynqmp_qspi.c new file +9 -0

+				| (GQSPI_DATA_DLY_ADJ_VALUE <<
+					GQSPI_DATA_DLY_ADJ_SHIFT));
+	} else if (reqhz < GQSPI_FREQ_150MHZ) {
+		lpbkdlyadj = readl(&regs->lpbkdly);
+		lpbkdlyadj |= ((GQSPI_LPBK_DLY_ADJ_USE_LPBK_MASK) |
+				GQSPI_LPBK_DLY_ADJ_DLY_0);
+	}
+
+	zynqmp_mmio_write(IOU_TAPDLY_BYPASS_OFST,

IOU_TAPDLY_BYPASS_MASK,

drivers/spi/zynqmp_qspi.c new file +30 -0

+			  tapdlybypass);
+	writel(lpbkdlyadj, &regs->lpbkdly);
+	writel(datadlyadj, &regs->gqspidlyadj);
+}
+
+static int zynqmp_qspi_set_speed(struct udevice *bus, uint speed)
+{
+	struct zynqmp_qspi_platdata *plat = bus->platdata;
+	struct zynqmp_qspi_priv *priv = dev_get_priv(bus);
+	struct zynqmp_qspi_regs *regs = priv->regs;
+	u32 confr;
+	u8 baud_rate_val = 0;
+
+	debug("%s\n", __func__);
+	if (speed > plat->frequency)
+		speed = plat->frequency;
+
+	/* Set the clock frequency */
+	confr = readl(&regs->confr);
+	if (speed == 0) {
+		/* Set baudrate x8, if the freq is 0 */
+		baud_rate_val = ZYNQMP_QSPI_DFLT_BAUD_RATE_VAL;
+	} else if (plat->speed_hz != speed) {
+		while ((baud_rate_val < 8) &&
+		       ((plat->frequency /
+		       (2 << baud_rate_val)) > speed))
+			baud_rate_val++;
+
+		if (baud_rate_val > ZYNQMP_QSPI_MAX_BAUD_RATE_VAL)
+			baud_rate_val =

ZYNQMP_QSPI_DFLT_BAUD_RATE_VAL; +

drivers/spi/zynqmp_qspi.c new file +1 -0

+		plat->speed_hz = plat->frequency / (2 <<

baud_rate_val);

drivers/spi/zynqmp_qspi.c new file +15 -0

+	}
+	confr &= ~ZYNQMP_QSPI_BAUD_DIV_MASK;
+	confr |= (baud_rate_val << 3);
+	writel(confr, &regs->confr);
+
+	zynqmp_qspi_set_tapdelay(bus, baud_rate_val);
+	debug("regs=%p, speed=%d\n", priv->regs, plat->speed_hz);
+
+	return 0;
+}
+
+static int zynqmp_qspi_child_pre_probe(struct udevice *bus)
+{
+	struct spi_slave *slave = dev_get_parent_priv(bus);
+	struct zynqmp_qspi_platdata *plat =

dev_get_platdata(bus->parent); +

drivers/spi/zynqmp_qspi.c new file +48 -0

+	slave->option = SF_SINGLE_FLASH;
+	slave->mode = plat->tx_rx_mode;
+
+	return 0;
+}
+
+static int zynqmp_qspi_probe(struct udevice *bus)
+{
+	struct zynqmp_qspi_platdata *plat = dev_get_platdata(bus);
+	struct zynqmp_qspi_priv *priv = dev_get_priv(bus);
+
+	debug("%s: bus:%p, priv:%p\n", __func__, bus, priv);
+
+	priv->regs = plat->regs;
+	priv->dma_regs = plat->dma_regs;
+
+	/* init the zynq spi hw */
+	zynqmp_qspi_init_hw(priv);
+
+	return 0;
+}
+
+static int zynqmp_qspi_set_mode(struct udevice *bus, uint mode)
+{
+	struct zynqmp_qspi_priv *priv = dev_get_priv(bus);
+	struct zynqmp_qspi_regs *regs = priv->regs;
+	u32 confr;
+
+	debug("%s\n", __func__);
+	/* Set the SPI Clock phase and polarities */
+	confr = readl(&regs->confr);
+	confr &= ~(ZYNQMP_QSPI_CONFIG_CPHA_MASK |
+		   ZYNQMP_QSPI_CONFIG_CPOL_MASK);
+
+	if (priv->mode & SPI_CPHA)
+		confr |= ZYNQMP_QSPI_CONFIG_CPHA_MASK;
+	if (priv->mode & SPI_CPOL)
+		confr |= ZYNQMP_QSPI_CONFIG_CPOL_MASK;
+
+	//writel(confr, &regs->confr);
+	priv->mode = mode;
+
+	debug("regs=%p, mode=%d\n", priv->regs, priv->mode);
+
+	return 0;
+}
+
+static int zynqmp_qspi_fill_tx_fifo(struct zynqmp_qspi_priv *priv,

u32 size) +{

drivers/spi/zynqmp_qspi.c new file +90 -0

+	u32 data;
+	u32 timeout = ZYNQMP_QSPI_TIMEOUT;
+	struct zynqmp_qspi_regs *regs = priv->regs;
+	u32 *buf = (u32 *)priv->tx_buf;
+	u32 len = size;
+
+	debug("TxFIFO: 0x%x, size: 0x%x\n", readl(&regs->isr),
+	      size);
+
+	while (size && timeout) {
+		if (readl(&regs->isr) &
+			ZYNQMP_QSPI_IXR_TXNFULL_MASK) {
+			if (size >= 4) {
+				writel(*buf, &regs->txd0r);
+				buf++;
+				size -= 4;
+			} else {
+				switch (size) {
+				case 1:
+					data = *((u8 *)buf);
+					buf += 1;
+					data |= 0xFFFFFF00;
+					break;
+				case 2:
+					data = *((u16 *)buf);
+					buf += 2;
+					data |= 0xFFFF0000;
+					break;
+				case 3:
+					data = *((u16 *)buf);
+					buf += 2;
+					data |= (*((u8 *)buf) << 16);
+					buf += 1;
+					data |= 0xFF000000;
+					break;
+				}
+				writel(data, &regs->txd0r);
+				size = 0;
+			}
+		} else {
+			udelay(1);
+			timeout--;
+		}
+	}
+	if (!timeout) {
+		printf("%s: Timeout\n", __func__);
+		return -1;
+	}
+
+	priv->tx_buf += len;
+	return 0;
+}
+
+static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv *priv)
+{
+	u8 command = 1;
+	u32 gen_fifo_cmd;
+	u32 bytecount = 0;
+
+	while (priv->len) {
+		gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
+		gen_fifo_cmd |= ZYNQMP_QSPI_GFIFO_TX;
+
+		if (command) {
+			command = 0;
+			last_cmd = *(u8 *)priv->tx_buf;
+		}
+
+		gen_fifo_cmd |= ZYNQMP_QSPI_SPI_MODE_SPI;
+		gen_fifo_cmd |= *(u8 *)priv->tx_buf;
+		bytecount++;
+		priv->len--;
+		priv->tx_buf = (u8 *)priv->tx_buf + 1;
+
+		debug("GFIFO_CMD_Cmd = 0x%x\n", gen_fifo_cmd);
+
+		zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
+	}
+}
+
+static u32 zynqmp_qspi_calc_exp(struct zynqmp_qspi_priv *priv,
+				u32 *gen_fifo_cmd)
+{
+	u32 expval = 8;
+	u32 len;
+
+	while (1) {
+		if (priv->len > 255) {
+			if (priv->len & (1 << expval)) {
+				*gen_fifo_cmd &=

~ZYNQMP_QSPI_GFIFO_IMD_MASK;

drivers/spi/zynqmp_qspi.c new file +1 -0

+				*gen_fifo_cmd |=

ZYNQMP_QSPI_GFIFO_EXP_MASK;

drivers/spi/zynqmp_qspi.c new file +7 -0

+				*gen_fifo_cmd |= expval;
+				priv->len -= (1 << expval);
+				return expval;
+			}
+			expval++;
+		} else {
+			*gen_fifo_cmd &=

~(ZYNQMP_QSPI_GFIFO_IMD_MASK |
+
ZYNQMP_QSPI_GFIFO_EXP_MASK);

drivers/spi/zynqmp_qspi.c new file +86 -0

+			*gen_fifo_cmd |= (u8)priv->len;
+			len = (u8)priv->len;
+			priv->len  = 0;
+			return len;
+		}
+	}
+}
+
+static int zynqmp_qspi_genfifo_fill_tx(struct zynqmp_qspi_priv *priv)
+{
+	u32 gen_fifo_cmd;
+	u32 len;
+	int ret = 0;
+
+	gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
+	gen_fifo_cmd |= ZYNQMP_QSPI_GFIFO_TX |
+			ZYNQMP_QSPI_GFIFO_DATA_XFR_MASK;
+
+	if (last_cmd == QUAD_PAGE_PROGRAM_CMD)
+		gen_fifo_cmd |= ZYNQMP_QSPI_SPI_MODE_QSPI;
+	else
+		gen_fifo_cmd |= ZYNQMP_QSPI_SPI_MODE_SPI;
+
+	while (priv->len) {
+		len = zynqmp_qspi_calc_exp(priv, &gen_fifo_cmd);
+		zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
+
+		debug("GFIFO_CMD_TX:0x%x\n", gen_fifo_cmd);
+
+		if (gen_fifo_cmd & ZYNQMP_QSPI_GFIFO_EXP_MASK)
+			ret = zynqmp_qspi_fill_tx_fifo(priv,
+						       1 << len);
+		else
+			ret = zynqmp_qspi_fill_tx_fifo(priv,
+						       len);
+
+		if (ret)
+			return ret;
+	}
+	return ret;
+}
+
+static int zynqmp_qspi_start_dma(struct zynqmp_qspi_priv *priv,
+				 u32 gen_fifo_cmd, u32 *buf)
+{
+	u32 addr;
+	u32 size, len;
+	u32 timeout = ZYNQMP_QSPI_TIMEOUT;
+	u32 actuallen = priv->len;
+	struct zynqmp_qspi_dma_regs *dma_regs = priv->dma_regs;
+
+	writel((unsigned long)buf, &dma_regs->dmadst);
+	writel(roundup(priv->len, 4), &dma_regs->dmasize);
+	writel(ZYNQMP_QSPI_DMA_DST_I_STS_MASK, &dma_regs->dmaier);
+	addr = (unsigned long)buf;
+	size = roundup(priv->len, ARCH_DMA_MINALIGN);
+	flush_dcache_range(addr, addr + size);
+
+	while (priv->len) {
+		len = zynqmp_qspi_calc_exp(priv, &gen_fifo_cmd);
+		if (!(gen_fifo_cmd & ZYNQMP_QSPI_GFIFO_EXP_MASK) &&
+		    (len % 4)) {
+			gen_fifo_cmd &= ~(0xFF);
+			gen_fifo_cmd |= (len / 4 + 1) * 4;
+		}
+		zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
+
+		debug("GFIFO_CMD_RX:0x%x\n", gen_fifo_cmd);
+	}
+
+	while (timeout) {
+		if (readl(&dma_regs->dmaisr) &
+		    ZYNQMP_QSPI_DMA_DST_I_STS_DONE) {
+			writel(ZYNQMP_QSPI_DMA_DST_I_STS_DONE,
+			       &dma_regs->dmaisr);
+			break;
+		}
+		udelay(1);
+		timeout--;
+	}
+
+	debug("buf:0x%lx, rxbuf:0x%lx, *buf:0x%x len: 0x%x\n",
+	      (unsigned long)buf, (unsigned long)priv->rx_buf, *buf,
+	      actuallen);
+	if (!timeout) {
+		printf("DMA Timeout:0x%x\n",

readl(&dma_regs->dmaisr));

drivers/spi/zynqmp_qspi.c new file +31 -0

+		return -1;
+	}
+
+	if (buf != priv->rx_buf)
+		memcpy(priv->rx_buf, buf, actuallen);
+
+	return 0;
+}
+
+static int zynqmp_qspi_genfifo_fill_rx(struct zynqmp_qspi_priv *priv)
+{
+	u32 gen_fifo_cmd;
+	u32 *buf;
+	u32 actuallen = priv->len;
+
+	gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
+	gen_fifo_cmd |= ZYNQMP_QSPI_GFIFO_RX |
+			ZYNQMP_QSPI_GFIFO_DATA_XFR_MASK;
+
+	if (last_cmd == QUAD_OUT_READ_CMD)
+		gen_fifo_cmd |= ZYNQMP_QSPI_SPI_MODE_QSPI;
+	else if (last_cmd == DUAL_OUTPUT_FASTRD_CMD)
+		gen_fifo_cmd |= ZYNQMP_QSPI_SPI_MODE_DUAL_SPI;
+	else
+		gen_fifo_cmd |= ZYNQMP_QSPI_SPI_MODE_SPI;
+
+	/*
+	 * Check if receive buffer is aligned to 4 byte and length
+	 * is multiples of four byte as we are using dma to receive.
+	 */
+	if (!((unsigned long)priv->rx_buf & (ZYNQMP_QSPI_DMA_ALIGN -

1)) &&

drivers/spi/zynqmp_qspi.c new file +3 -0

+	    !(actuallen % ZYNQMP_QSPI_DMA_ALIGN)) {
+		buf = (u32 *)priv->rx_buf;
+		return zynqmp_qspi_start_dma(priv, gen_fifo_cmd,

buf);

drivers/spi/zynqmp_qspi.c new file +4 -0

+	}
+
+	ALLOC_CACHE_ALIGN_BUFFER(u8, tmp, roundup(priv->len,
+

ZYNQMP_QSPI_DMA_ALIGN));

drivers/spi/zynqmp_qspi.c new file +85 -0

+	buf = (u32 *)tmp;
+	return zynqmp_qspi_start_dma(priv, gen_fifo_cmd, buf);
+}
+
+static int zynqmp_qspi_start_transfer(struct zynqmp_qspi_priv *priv)
+{
+	int ret = 0;
+
+	if (priv->is_inst) {
+		if (priv->tx_buf)
+			zynqmp_qspi_genfifo_cmd(priv);
+		else
+			ret = -1;
+	} else {
+		if (priv->tx_buf)
+			ret = zynqmp_qspi_genfifo_fill_tx(priv);
+		else if (priv->rx_buf)
+			ret = zynqmp_qspi_genfifo_fill_rx(priv);
+		else
+			ret = -1;
+	}
+	return ret;
+}
+
+static int zynqmp_qspi_transfer(struct zynqmp_qspi_priv *priv)
+{
+	static unsigned int cs_change = 1;
+	int status = 0;
+
+	debug("%s\n", __func__);
+
+	while (1) {
+		/* Select the chip if required */
+		if (cs_change)
+			zynqmp_qspi_chipselect(priv, 1);
+
+		cs_change = priv->cs_change;
+
+		if (!priv->tx_buf && !priv->rx_buf && priv->len) {
+			status = -1;
+			break;
+		}
+
+		/* Request the transfer */
+		if (priv->len) {
+			status = zynqmp_qspi_start_transfer(priv);
+			priv->is_inst = 0;
+			if (status < 0)
+				break;
+		}
+
+		if (cs_change)
+			/* Deselect the chip */
+			zynqmp_qspi_chipselect(priv, 0);
+		break;
+	}
+
+	return status;
+}
+
+static int zynqmp_qspi_claim_bus(struct udevice *dev)
+{
+	struct udevice *bus = dev->parent;
+	struct zynqmp_qspi_priv *priv = dev_get_priv(bus);
+	struct zynqmp_qspi_regs *regs = priv->regs;
+
+	debug("%s\n", __func__);
+	writel(ZYNQMP_QSPI_ENABLE_ENABLE_MASK, &regs->enbr);
+
+	return 0;
+}
+
+static int zynqmp_qspi_release_bus(struct udevice *dev)
+{
+	struct udevice *bus = dev->parent;
+	struct zynqmp_qspi_priv *priv = dev_get_priv(bus);
+	struct zynqmp_qspi_regs *regs = priv->regs;
+
+	debug("%s\n", __func__);
+	writel(~ZYNQMP_QSPI_ENABLE_ENABLE_MASK, &regs->enbr);
+
+	return 0;
+}
+
+int zynqmp_qspi_xfer(struct udevice *dev, unsigned int bitlen, const

void *dout,

drivers/spi/zynqmp_qspi.c new file +6 -0

+		     void *din, unsigned long flags)
+{
+	struct udevice *bus = dev->parent;
+	struct zynqmp_qspi_priv *priv = dev_get_priv(bus);
+
+	debug("%s: priv: 0x%08lx bitlen: %d dout: 0x%08lx ",

__func__,

drivers/spi/zynqmp_qspi.c new file +2 -0

+	      (unsigned long)priv, bitlen, (unsigned long)dout);
+	debug("din: 0x%08lx flags: 0x%lx\n", (unsigned long)din,

flags); +

drivers/spi/zynqmp_qspi.c new file +44 -0

+	priv->tx_buf = dout;
+	priv->rx_buf = din;
+	priv->len = bitlen / 8;
+
+	/*
+	 * Festering sore.
+	 * Assume that the beginning of a transfer with bits to
+	 * transmit must contain a device command.
+	 */
+	if (dout && flags & SPI_XFER_BEGIN)
+		priv->is_inst = 1;
+	else
+		priv->is_inst = 0;
+
+	if (flags & SPI_XFER_END)
+		priv->cs_change = 1;
+	else
+		priv->cs_change = 0;
+
+	zynqmp_qspi_transfer(priv);
+
+	return 0;
+}
+
+static const struct dm_spi_ops zynqmp_qspi_ops = {
+	.claim_bus      = zynqmp_qspi_claim_bus,
+	.release_bus    = zynqmp_qspi_release_bus,
+	.xfer           = zynqmp_qspi_xfer,
+	.set_speed      = zynqmp_qspi_set_speed,
+	.set_mode       = zynqmp_qspi_set_mode,
+};
+
+static const struct udevice_id zynqmp_qspi_ids[] = {
+	{ .compatible = "xlnx,zynqmp-qspi-1.0" },
+	{ }
+};
+
+U_BOOT_DRIVER(zynqmp_qspi) = {
+	.name   = "zynqmp_qspi",
+	.id     = UCLASS_SPI,
+	.of_match = zynqmp_qspi_ids,
+	.ops    = &zynqmp_qspi_ops,
+	.ofdata_to_platdata = zynqmp_qspi_ofdata_to_platdata,
+	.platdata_auto_alloc_size = sizeof(struct

zynqmp_qspi_platdata),

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 2:40 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>; Siva Durga Prasad Paladugu <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 2 lines · Siva Durga Prasad Paladugu

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

Legacy question, what is your approach for dual memory setup? Did you write another flash driver?

I see this driver use dual flash slave 'option' which doesn't live on spi side anymore. better to have a discussion on approach and will review further.

thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.

Hi Jagan,

Quoted 9 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 2:40 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>; Siva Durga Prasad Paladugu <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 7 lines

Quoted 2 lines · Siva Durga Prasad Paladugu

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

Legacy question, what is your approach for dual memory setup? Did you write another flash driver?

No

Quoted 1 line

Quoted 2 lines

I see this driver use dual flash slave 'option' which doesn't live on spi side anymore. better to have a discussion on approach and will review further.

I can see that spi_flash.c(driver/mtd/spi/spi_flash.c) has the option for dual flash under CONFIG_SF_DUAL_FLASH. I thought of using the same. Isn't it takes care of dual flash case?
Please let me know if you any further thoughts on how it has to be handled.

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 3:01 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 11 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 9 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 2:40 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>; Siva Durga Prasad Paladugu <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 12 lines

Quoted 7 lines

Quoted 2 lines · Siva Durga Prasad Paladugu

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

Legacy question, what is your approach for dual memory setup? Did you write another flash driver?

No

Quoted 3 lines

I see this driver use dual flash slave 'option' which doesn't live on spi side anymore. better to have a discussion on approach and will

review further.

Quoted 2 lines

I can see that spi_flash.c(driver/mtd/spi/spi_flash.c) has the option for

dual flash under CONFIG_SF_DUAL_FLASH.

Quoted 2 lines

I thought of using the same. Isn't it takes care of dual flash case? Please let me know if you any further thoughts on how it has to be

handled.

Dual flash case should take for generic spi drivers, if you strictly want your controller to handle flash device rather !flashes then we need to write the driver at flash side. ie why I asked as first question.

thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.

Hi Jagan,

Quoted 41 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 3:01 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 11 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 9 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 2:40 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>; Siva Durga Prasad Paladugu <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 12 lines

Quoted 7 lines

Quoted 2 lines · Siva Durga Prasad Paladugu

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

Legacy question, what is your approach for dual memory setup? Did you write another flash driver?

No

Quoted 3 lines

I see this driver use dual flash slave 'option' which doesn't live on spi side anymore. better to have a discussion on approach and will

review further.

Quoted 2 lines

I can see that spi_flash.c(driver/mtd/spi/spi_flash.c) has the option for

dual flash under CONFIG_SF_DUAL_FLASH.

Quoted 2 lines

I thought of using the same. Isn't it takes care of dual flash case? Please let me know if you any further thoughts on how it has to be

handled.

Quoted 3 lines

Dual flash case should take for generic spi drivers, if you strictly want your controller to handle flash device rather !flashes then we need to write the driver at flash side. ie why I asked as first question.

Does this mean that drivers that are present in drivers/spi/ should work for both flashes and !flashes. And the drivers that only targets flash devices should be in different place and doesn’t use Dual flash functionality under CONFIG_SF_DUAL_FLASH? Or it can still use this.

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Wednesday, November 01, 2017 2:54 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 19 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 17 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 3:01 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 7 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 5 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 2:40 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>;

Siva

Quoted 26 lines

Quoted 26 lines

Quoted 4 lines

Quoted 4 lines

Durga Prasad Paladugu <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 13 lines

Quoted 7 lines

Quoted 2 lines · Siva Durga Prasad Paladugu

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

Legacy question, what is your approach for dual memory setup? Did you write another flash driver?

No

Quoted 4 lines

I see this driver use dual flash slave 'option' which doesn't live on spi side anymore. better to have a discussion on approach and will

review further.

Quoted 3 lines

I can see that spi_flash.c(driver/mtd/spi/spi_flash.c) has the option for

dual flash under CONFIG_SF_DUAL_FLASH.

Quoted 2 lines

I thought of using the same. Isn't it takes care of dual flash case? Please let me know if you any further thoughts on how it has to be

handled.

Quoted 7 lines

Quoted 3 lines

Dual flash case should take for generic spi drivers, if you strictly want your controller to handle flash device rather !flashes then we need to write the driver at flash side. ie why I asked as first question.

Does this mean that drivers that are present in drivers/spi/ should work for both flashes and !flashes. And the drivers that only targets flash devices should be in different place and doesn’t use Dual flash

functionality under CONFIG_SF_DUAL_FLASH? Or it can still use this.

Sorry, you understand it reverse or may be I'm not clear.

drivers at drivers/spi can handle only generic slaves which includes spi-flash and some spi-flash(spi-nor) controllers which only deals with spi-flash slaves which can be part of drivers/mtd/spi. Since your driver is categorized as spi-nor controller(in above notes from you) it's better to write driver at drivers/mtd/spi side.

Hope it clear.

thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.

-----Original Message-----
From: Siva Durga Prasad Paladugu
Sent: Thursday, November 23, 2017 1:01 PM
To: Jagan Teki <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: RE: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Hi Jagan,

Quoted 22 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Wednesday, November 01, 2017 2:54 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 12 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 10 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 3:01 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

On Tue, Oct 31, 2017 at 2:50 PM, Siva Durga Prasad Paladugu <[email protected]> wrote:

Quoted 38 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Hi Jagan,

Quoted 5 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 2:40 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>;

Siva

Quoted 30 lines

Quoted 30 lines

Quoted 4 lines

Quoted 4 lines

Durga Prasad Paladugu <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 13 lines

Quoted 7 lines

Quoted 2 lines · Siva Durga Prasad Paladugu

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

Legacy question, what is your approach for dual memory setup? Did you write another flash driver?

No

Quoted 4 lines

I see this driver use dual flash slave 'option' which doesn't live on spi side anymore. better to have a discussion on approach and will

review further.

Quoted 3 lines

I can see that spi_flash.c(driver/mtd/spi/spi_flash.c) has the option for

dual flash under CONFIG_SF_DUAL_FLASH.

Quoted 3 lines

I thought of using the same. Isn't it takes care of dual flash case? Please let me know if you any further thoughts on how it has to be

handled.

Dual flash case should take for generic spi drivers, if you strictly want your controller to handle flash device rather !flashes then we need to write the driver at flash side. ie why I asked as

first question.

Quoted 7 lines

Quoted 5 lines

Does this mean that drivers that are present in drivers/spi/ should work for both flashes and !flashes. And the drivers that only targets flash devices should be in different place and doesn’t use Dual flash

functionality under CONFIG_SF_DUAL_FLASH? Or it can still use this.

Quoted 7 lines

Sorry, you understand it reverse or may be I'm not clear.

drivers at drivers/spi can handle only generic slaves which includes spi-flash and some spi-flash(spi-nor) controllers which only deals with spi-flash slaves which can be part of drivers/mtd/spi. Since your driver is categorized as spi-nor controller(in above notes from you) it's better to write driver at drivers/mtd/spi side.

No, the controller is meant to handle other slaves as well along with spi-nor. Also for now, we are targeting single spi flash. So, keeping the driver here should just be fine. Please let me know if you need any further info.

Thanks,
Siva.

Quoted 8 lines

Hope it clear.

thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.

Hi Jagan,

Quoted 65 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Wednesday, November 01, 2017 2:54 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 19 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 17 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 3:01 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 7 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 5 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 2:40 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>;

Siva

Quoted 26 lines

Quoted 26 lines

Quoted 4 lines

Quoted 4 lines

Durga Prasad Paladugu <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 13 lines

Quoted 7 lines

Quoted 2 lines · Siva Durga Prasad Paladugu

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

Legacy question, what is your approach for dual memory setup? Did you write another flash driver?

No

Quoted 4 lines

I see this driver use dual flash slave 'option' which doesn't live on spi side anymore. better to have a discussion on approach and will

review further.

Quoted 3 lines

I can see that spi_flash.c(driver/mtd/spi/spi_flash.c) has the option for

dual flash under CONFIG_SF_DUAL_FLASH.

Quoted 2 lines

I thought of using the same. Isn't it takes care of dual flash case? Please let me know if you any further thoughts on how it has to be

handled.

Quoted 7 lines

Quoted 3 lines

Dual flash case should take for generic spi drivers, if you strictly want your controller to handle flash device rather !flashes then we need to write the driver at flash side. ie why I asked as first question.

Does this mean that drivers that are present in drivers/spi/ should work for both flashes and !flashes. And the drivers that only targets flash devices should be in different place and doesn’t use Dual flash

functionality under CONFIG_SF_DUAL_FLASH? Or it can still use this.

Quoted 7 lines

Sorry, you understand it reverse or may be I'm not clear.

drivers at drivers/spi can handle only generic slaves which includes spi-flash and some spi-flash(spi-nor) controllers which only deals with spi-flash slaves which can be part of drivers/mtd/spi. Since your driver is categorized as spi-nor controller(in above notes from you) it's better to write driver at drivers/mtd/spi side.

No, the controller is meant to handle other slaves as well along with spi-nor. Also for now, we are targeting single spi flash. So, keeping the driver here should just be fine. Please let me know if you need any further info.

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Thursday, December 07, 2017 10:56 AM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 62 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 60 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Wednesday, November 01, 2017 2:54 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 19 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 17 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 3:01 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 7 lines · Siva Durga Prasad Paladugu

Hi Jagan,

Quoted 5 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, October 31, 2017 2:40 PM
To: Siva Durga Prasad Paladugu <[email protected]>
Cc: u-boot at lists.denx.de; Liam Beguin <[email protected]>;

Siva

Quoted 30 lines

Quoted 30 lines

Quoted 4 lines

Quoted 4 lines

Durga Prasad Paladugu <[email protected]>
Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

Quoted 13 lines

Quoted 7 lines

Quoted 2 lines · Siva Durga Prasad Paladugu

This patch adds qspi driver support for ZynqMP SoC. This driver is responsible for communicating with qspi flash devices.

Legacy question, what is your approach for dual memory setup? Did you write another flash driver?

No

Quoted 4 lines

I see this driver use dual flash slave 'option' which doesn't live on spi side anymore. better to have a discussion on approach and will

review further.

Quoted 3 lines

I can see that spi_flash.c(driver/mtd/spi/spi_flash.c) has the option for

dual flash under CONFIG_SF_DUAL_FLASH.

Quoted 3 lines

I thought of using the same. Isn't it takes care of dual flash case? Please let me know if you any further thoughts on how it has to be

handled.

Dual flash case should take for generic spi drivers, if you strictly want your controller to handle flash device rather !flashes then we need to write the driver at flash side. ie why I asked

as first question.

Quoted 15 lines

Quoted 14 lines

Quoted 5 lines

Does this mean that drivers that are present in drivers/spi/ should work for both flashes and !flashes. And the drivers that only targets flash devices should be in different place and doesn’t use Dual flash

functionality under CONFIG_SF_DUAL_FLASH? Or it can still use this.

Sorry, you understand it reverse or may be I'm not clear.

drivers at drivers/spi can handle only generic slaves which includes spi-flash and some spi-flash(spi-nor) controllers which only deals with spi-flash slaves which can be part of drivers/mtd/spi. Since your driver is categorized as spi-nor controller(in above notes from you) it's better to write driver at drivers/mtd/spi side.

Quoted 1 line

No, the controller is meant to handle other slaves as well along with spi-

nor.

Quoted 2 lines

Also for now, we are targeting single spi flash. So, keeping the driver here should just be fine. Please let me know if you need any further

info.

remember if driver sits here, then we can't extent your controller specific functions.

And rebase your patches and set it again.