[U-Boot] [PATCH 0/4] Convert omap3-spi driver to Driver Model

[U-Boot] [PATCH 0/4] Convert omap3-spi driver to Driver Model

[Christophe Ricard]

Hi Simon,

This patchset tries to convert the TI omap3_spi driver to Driver Model.
It has been tested on a TI BeagleBoard xM.

Best Regards
Christophe



Christophe Ricard (4):
  spi: omap3: Remove unused variable irqstatus in omap3_spi_txrx
  spi: spi-uclass: Set slave wordlen with SPI_DEFAULT_WORDLEN
  spi: omap3: Convert to DM
  spi: omap3: Convert fully to DM_SPI

 drivers/spi/Kconfig      |   6 +
 drivers/spi/omap3_spi.c  | 411 +++++++++++++++++++++++++++--------------------
 drivers/spi/omap3_spi.h  | 109 -------------
 drivers/spi/spi-uclass.c |   1 +
 4 files changed, 240 insertions(+), 287 deletions(-)
 delete mode 100644 drivers/spi/omap3_spi.h

-- 
2.5.0

[U-Boot] [PATCH 1/4] spi: omap3: Remove unused variable irqstatus in omap3_spi_txrx

[Christophe Ricard]

Remove unused variable irqstatus in omap3_spi_txrx

Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
---

 drivers/spi/omap3_spi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 85f9e85..95cdfa3 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -336,7 +336,6 @@ int omap3_spi_txrx(struct spi_slave *slave, unsigned int len,
 	struct omap3_spi_slave *ds = to_omap3_spi(slave);
 	ulong start;
 	int chconf = readl(&ds->regs->channel[ds->slave.cs].chconf);
-	int irqstatus = readl(&ds->regs->irqstatus);
 	int i=0;
 
 	/*Enable SPI channel*/
@@ -351,7 +350,6 @@ int omap3_spi_txrx(struct spi_slave *slave, unsigned int len,
 	/*Shift in and out 1 byte at time*/
 	for (i=0; i < len; i++){
 		/* Write: wait for TX empty (TXS == 1)*/
-		irqstatus |= (1<< (4*(ds->slave.bus)));
 		start = get_timer(0);
 		while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) &
 			 OMAP3_MCSPI_CHSTAT_TXS)) {
-- 
2.5.0

[U-Boot] [PATCH 2/4] spi: spi-uclass: Set slave wordlen with SPI_DEFAULT_WORDLEN

[Christophe Ricard]

In some case wordlen may not be set. Use SPI_DEFAULT_WORDLEN as default.

Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
---

 drivers/spi/spi-uclass.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 677c020..5561f36 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -158,6 +158,7 @@ static int spi_child_pre_probe(struct udevice *dev)
 	slave->max_hz = plat->max_hz;
 	slave->mode = plat->mode;
 	slave->mode_rx = plat->mode_rx;
+	slave->wordlen = SPI_DEFAULT_WORDLEN;
 
 	return 0;
 }
-- 
2.5.0

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Christophe Ricard]

Convert omap3_spi driver to DM and keep compatibility with previous
mode.

Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
---

 drivers/spi/Kconfig     |   6 +
 drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
 drivers/spi/omap3_spi.h |  14 +-
 3 files changed, 402 insertions(+), 57 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2cdb110..b8c2498 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -155,6 +155,12 @@ config ZYNQ_QSPI
 	  Zynq QSPI IP core. This IP is used to connect the flash in
 	  4-bit qspi, 8-bit dual stacked and shared 4-bit dual parallel.
 
+config OMAP3_SPI
+	bool "McSPI driver for OMAP"
+	help
+	  SPI master controller for OMAP24XX and later Multichannel SPI
+	  (McSPI) modules.
+
 endif # if DM_SPI
 
 config FSL_ESPI
diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 95cdfa3..09fb1ef 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -11,10 +11,14 @@
  *
  * Modified by Ruslan Araslanov <ruslan.araslanov@vitecmm.com>
  *
+ * Copyright (c) 2016 Christophe Ricard <christophe.ricard@gmail.com>
+ * - Added support for DM_SPI
+ *
  * SPDX-License-Identifier:	GPL-2.0+
  */
 
 #include <common.h>
+#include <dm.h>
 #include <spi.h>
 #include <malloc.h>
 #include <asm/io.h>
@@ -22,9 +26,17 @@
 
 #define SPI_WAIT_TIMEOUT 10
 
+#ifdef CONFIG_DM_SPI
+static void spi_reset(struct udevice *dev)
+#else
 static void spi_reset(struct omap3_spi_slave *ds)
+#endif
 {
 	unsigned int tmp;
+#ifdef CONFIG_DM_SPI
+	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+
+#endif
 
 	writel(OMAP3_MCSPI_SYSCONFIG_SOFTRESET, &ds->regs->sysconfig);
 	do {
@@ -39,20 +51,50 @@ static void spi_reset(struct omap3_spi_slave *ds)
 	writel(OMAP3_MCSPI_WAKEUPENABLE_WKEN, &ds->regs->wakeupenable);
 }
 
+#ifdef CONFIG_DM_SPI
+static void omap3_spi_write_chconf(struct udevice *dev, int val)
+#else
 static void omap3_spi_write_chconf(struct omap3_spi_slave *ds, int val)
+#endif
 {
-	writel(val, &ds->regs->channel[ds->slave.cs].chconf);
+	unsigned int cs;
+#ifdef CONFIG_DM_SPI
+	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+
+
+	cs = platdata->cs;
+#else
+	cs = ds->slave.cs;
+#endif
+
+	writel(val, &ds->regs->channel[cs].chconf);
 	/* Flash post writes to make immediate effect */
-	readl(&ds->regs->channel[ds->slave.cs].chconf);
+	readl(&ds->regs->channel[cs].chconf);
 }
 
+#ifdef CONFIG_DM_SPI
+static void omap3_spi_set_enable(struct udevice *dev, int enable)
+#else
 static void omap3_spi_set_enable(struct omap3_spi_slave *ds, int enable)
+#endif
 {
-	writel(enable, &ds->regs->channel[ds->slave.cs].chctrl);
+	unsigned int cs;
+#ifdef CONFIG_DM_SPI
+	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+
+	cs = platdata->cs;
+#else
+	cs = ds->slave.cs;
+#endif
+
+	writel(enable, &ds->regs->channel[cs].chctrl);
 	/* Flash post writes to make immediate effect */
-	readl(&ds->regs->channel[ds->slave.cs].chctrl);
+	readl(&ds->regs->channel[cs].chctrl);
 }
 
+#ifndef CONFIG_DM_SPI
 void spi_init()
 {
 	/* do nothing */
@@ -138,10 +180,32 @@ void spi_free_slave(struct spi_slave *slave)
 	free(ds);
 }
 
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+	return 1;
+}
+#endif
+
+#ifdef CONFIG_DM_SPI
+static int omap3_spi_claim_bus(struct udevice *dev)
+#else
 int spi_claim_bus(struct spi_slave *slave)
+#endif
 {
-	struct omap3_spi_slave *ds = to_omap3_spi(slave);
+	unsigned int cs;
+	struct omap3_spi_slave *ds;
 	unsigned int conf, div = 0;
+#ifdef CONFIG_DM_SPI
+	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+	struct spi_slave *slave = dev_get_parent_priv(dev);
+
+	ds = dev_get_priv(dev->parent);
+	cs = platdata->cs;
+	ds->freq = slave->max_hz;
+#else
+	ds = to_omap3_spi(slave);
+	cs = ds->slave.cs;
+#endif
 
 	/* McSPI global module configuration */
 
@@ -149,7 +213,11 @@ int spi_claim_bus(struct spi_slave *slave)
 	 * setup when switching from (reset default) slave mode
 	 * to single-channel master mode
 	 */
+#ifdef CONFIG_DM_SPI
+	spi_reset(dev);
+#else
 	spi_reset(ds);
+#endif
 	conf = readl(&ds->regs->modulctrl);
 	conf &= ~(OMAP3_MCSPI_MODULCTRL_STEST | OMAP3_MCSPI_MODULCTRL_MS);
 	conf |= OMAP3_MCSPI_MODULCTRL_SINGLE;
@@ -165,8 +233,7 @@ int spi_claim_bus(struct spi_slave *slave)
 	} else
 		div = 0xC;
 
-	conf = readl(&ds->regs->channel[ds->slave.cs].chconf);
-
+	conf = readl(&ds->regs->channel[cs].chconf);
 	/* standard 4-wire master mode:	SCK, MOSI/out, MISO/in, nCS
 	 * REVISIT: this controller could support SPI_3WIRE mode.
 	 */
@@ -184,7 +251,7 @@ int spi_claim_bus(struct spi_slave *slave)
 
 	/* wordlength */
 	conf &= ~OMAP3_MCSPI_CHCONF_WL_MASK;
-	conf |= (ds->slave.wordlen - 1) << 7;
+	conf |= (slave->wordlen - 1) << 7;
 
 	/* set chipselect polarity; manage with FORCE */
 	if (!(ds->mode & SPI_CS_HIGH))
@@ -209,113 +276,222 @@ int spi_claim_bus(struct spi_slave *slave)
 	/* Transmit & receive mode */
 	conf &= ~OMAP3_MCSPI_CHCONF_TRM_MASK;
 
+#ifdef CONFIG_DM_SPI
+	omap3_spi_write_chconf(dev, conf);
+#else
 	omap3_spi_write_chconf(ds,conf);
+#endif
 
 	return 0;
 }
 
+#ifdef CONFIG_DM_SPI
+int omap3_spi_release_bus(struct udevice *dev)
+#else
 void spi_release_bus(struct spi_slave *slave)
+#endif
 {
+#ifndef CONFIG_DM_SPI
 	struct omap3_spi_slave *ds = to_omap3_spi(slave);
-
+#endif
 	/* Reset the SPI hardware */
+#ifdef CONFIG_DM_SPI
+	spi_reset(dev);
+#else
 	spi_reset(ds);
+#endif
+
+#ifdef CONFIG_DM_SPI
+	return 0;
+#endif
 }
 
+#ifdef CONFIG_DM_SPI
+int omap3_spi_write(struct udevice *dev, unsigned int len, const void *txp,
+		    unsigned long flags)
+#else
 int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp,
 		    unsigned long flags)
+#endif
 {
-	struct omap3_spi_slave *ds = to_omap3_spi(slave);
-	int i;
+	struct omap3_spi_slave *ds;
+	int i, chconf;
 	ulong start;
-	int chconf = readl(&ds->regs->channel[ds->slave.cs].chconf);
+	unsigned int cs;
+#ifdef CONFIG_DM_SPI
+	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+	struct spi_slave *slave = dev_get_parent_priv(dev);
+
 
+	ds = dev_get_priv(dev->parent);
+	cs = platdata->cs;
+#else
+	ds = to_omap3_spi(slave);
+	cs = ds->slave.cs;
+#endif
+
+	chconf = readl(&ds->regs->channel[cs].chconf);
+
+#ifdef CONFIG_DM_SPI
 	/* Enable the channel */
-	omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN);
+	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN);
+#else
+	/* Enable the channel */
+	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN);
+#endif
 
 	chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK);
+#ifdef CONFIG_DM_SPI
+	chconf |= (slave->wordlen - 1) << 7;
+#else
 	chconf |= (ds->slave.wordlen - 1) << 7;
+#endif
 	chconf |= OMAP3_MCSPI_CHCONF_TRM_TX_ONLY;
 	chconf |= OMAP3_MCSPI_CHCONF_FORCE;
-	omap3_spi_write_chconf(ds,chconf);
+#ifdef CONFIG_DM_SPI
+	omap3_spi_write_chconf(dev, chconf);
+#else
+	omap3_spi_write_chconf(ds, chconf);
+#endif
 
 	for (i = 0; i < len; i++) {
 		/* wait till TX register is empty (TXS == 1) */
 		start = get_timer(0);
-		while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) &
+		while (!(readl(&ds->regs->channel[cs].chstat) &
 			 OMAP3_MCSPI_CHSTAT_TXS)) {
 			if (get_timer(start) > SPI_WAIT_TIMEOUT) {
 				printf("SPI TXS timed out, status=0x%08x\n",
-				       readl(&ds->regs->channel[ds->slave.cs].chstat));
+				       readl(&ds->regs->channel[cs].chstat));
 				return -1;
 			}
 		}
+
 		/* Write the data */
-		unsigned int *tx = &ds->regs->channel[ds->slave.cs].tx;
+		unsigned int *tx = &ds->regs->channel[cs].tx;
+#ifdef CONFIG_DM_SPI
+		if (slave->wordlen > 16)
+#else
 		if (ds->slave.wordlen > 16)
+#endif
 			writel(((u32 *)txp)[i], tx);
+#ifdef CONFIG_DM_SPI
+		else if (slave->wordlen > 8)
+#else
 		else if (ds->slave.wordlen > 8)
+#endif
 			writel(((u16 *)txp)[i], tx);
 		else
 			writel(((u8 *)txp)[i], tx);
 	}
 
 	/* wait to finish of transfer */
-	while ((readl(&ds->regs->channel[ds->slave.cs].chstat) &
+	while ((readl(&ds->regs->channel[cs].chstat) &
 			 (OMAP3_MCSPI_CHSTAT_EOT | OMAP3_MCSPI_CHSTAT_TXS)) !=
-			 (OMAP3_MCSPI_CHSTAT_EOT | OMAP3_MCSPI_CHSTAT_TXS));
+			 (OMAP3_MCSPI_CHSTAT_EOT | OMAP3_MCSPI_CHSTAT_TXS))
+		;
 
+#ifdef CONFIG_DM_SPI
+	/* Disable the channel otherwise the next immediate RX will get affected */
+	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS);
+#else
 	/* Disable the channel otherwise the next immediate RX will get affected */
-	omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS);
+	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS);
+#endif
 
 	if (flags & SPI_XFER_END) {
 
 		chconf &= ~OMAP3_MCSPI_CHCONF_FORCE;
-		omap3_spi_write_chconf(ds,chconf);
+#ifdef CONFIG_DM_SPI
+		omap3_spi_write_chconf(dev, chconf);
+#else
+		omap3_spi_write_chconf(ds, chconf);
+#endif
 	}
+
 	return 0;
 }
 
+#ifdef CONFIG_DM_SPI
+int omap3_spi_read(struct udevice *dev, unsigned int len, void *rxp,
+		   unsigned long flags)
+#else
 int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
 		   unsigned long flags)
+#endif
 {
-	struct omap3_spi_slave *ds = to_omap3_spi(slave);
-	int i;
+	struct omap3_spi_slave *ds;
+	int i, chconf;
 	ulong start;
-	int chconf = readl(&ds->regs->channel[ds->slave.cs].chconf);
+	unsigned int cs;
+#ifdef CONFIG_DM_SPI
+	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+	struct spi_slave *slave = dev_get_parent_priv(dev);
 
+
+	ds = dev_get_priv(dev->parent);
+	cs = platdata->cs;
+#else
+	ds = to_omap3_spi(slave);
+	cs = ds->slave.cs;
+#endif
+	chconf = readl(&ds->regs->channel[cs].chconf);
+
+#ifdef CONFIG_DM_SPI
+	/* Enable the channel */
+	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN);
+#else
 	/* Enable the channel */
-	omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN);
+	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN);
+#endif
 
 	chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK);
+#ifdef CONFIG_DM_SPI
+	chconf |= (slave->wordlen - 1) << 7;
+#else
 	chconf |= (ds->slave.wordlen - 1) << 7;
+#endif
 	chconf |= OMAP3_MCSPI_CHCONF_TRM_RX_ONLY;
 	chconf |= OMAP3_MCSPI_CHCONF_FORCE;
-	omap3_spi_write_chconf(ds,chconf);
+#ifdef CONFIG_DM_SPI
+	omap3_spi_write_chconf(dev, chconf);
+#else
+	omap3_spi_write_chconf(ds, chconf);
+#endif
 
-	writel(0, &ds->regs->channel[ds->slave.cs].tx);
+	writel(0, &ds->regs->channel[cs].tx);
 
 	for (i = 0; i < len; i++) {
 		start = get_timer(0);
 		/* Wait till RX register contains data (RXS == 1) */
-		while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) &
+		while (!(readl(&ds->regs->channel[cs].chstat) &
 			 OMAP3_MCSPI_CHSTAT_RXS)) {
 			if (get_timer(start) > SPI_WAIT_TIMEOUT) {
 				printf("SPI RXS timed out, status=0x%08x\n",
-				       readl(&ds->regs->channel[ds->slave.cs].chstat));
+				       readl(&ds->regs->channel[cs].chstat));
 				return -1;
 			}
 		}
-
 		/* Disable the channel to prevent furher receiving */
 		if(i == (len - 1))
-			omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS);
+#ifdef CONFIG_DM_SPI
+			omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS);
+#else
+			omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS);
+#endif
 
 		/* Read the data */
-		unsigned int *rx = &ds->regs->channel[ds->slave.cs].rx;
+		unsigned int *rx = &ds->regs->channel[cs].rx;
+#ifdef CONFIG_DM_SPI
+		if (slave->wordlen > 16)
+#else
 		if (ds->slave.wordlen > 16)
+#endif
 			((u32 *)rxp)[i] = readl(rx);
+#ifdef CONFIG_DM_SPI
+		else if (slave->wordlen > 8)
+#else
 		else if (ds->slave.wordlen > 8)
+#endif
 			((u16 *)rxp)[i] = (u16)readl(rx);
 		else
 			((u8 *)rxp)[i] = (u8)readl(rx);
@@ -323,89 +499,177 @@ int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
 
 	if (flags & SPI_XFER_END) {
 		chconf &= ~OMAP3_MCSPI_CHCONF_FORCE;
-		omap3_spi_write_chconf(ds,chconf);
+#ifdef CONFIG_DM_SPI
+		omap3_spi_write_chconf(dev, chconf);
+#else
+		omap3_spi_write_chconf(ds, chconf);
+#endif
 	}
 
 	return 0;
 }
 
+#ifdef CONFIG_DM_SPI
+/*McSPI Transmit Receive Mode*/
+int omap3_spi_txrx(struct udevice *dev, unsigned int len,
+		   const void *txp, void *rxp, unsigned long flags)
+#else
 /*McSPI Transmit Receive Mode*/
 int omap3_spi_txrx(struct spi_slave *slave, unsigned int len,
 		   const void *txp, void *rxp, unsigned long flags)
+#endif
 {
-	struct omap3_spi_slave *ds = to_omap3_spi(slave);
+	struct omap3_spi_slave *ds;
 	ulong start;
-	int chconf = readl(&ds->regs->channel[ds->slave.cs].chconf);
+	int chconf;
 	int i=0;
+	unsigned int cs;
+#ifdef CONFIG_DM_SPI
+	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+	struct spi_slave *slave = dev_get_parent_priv(dev);
+
 
+	ds = dev_get_priv(dev->parent);
+	cs = platdata->cs;
+#else
+	ds = to_omap3_spi(slave);
+	cs = ds->slave.cs;
+#endif
+	chconf = readl(&ds->regs->channel[cs].chconf);
+
+#ifdef CONFIG_DM_SPI
+	/*Enable SPI channel*/
+	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN);
+#else
 	/*Enable SPI channel*/
-	omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN);
+	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN);
+#endif
 
 	/*set TRANSMIT-RECEIVE Mode*/
 	chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK);
+#ifdef CONFIG_DM_SPI
+	chconf |= (slave->wordlen - 1) << 7;
+#else
 	chconf |= (ds->slave.wordlen - 1) << 7;
+#endif
 	chconf |= OMAP3_MCSPI_CHCONF_FORCE;
-	omap3_spi_write_chconf(ds,chconf);
+#ifdef CONFIG_DM_SPI
+	omap3_spi_write_chconf(dev, chconf);
+#else
+	omap3_spi_write_chconf(ds, chconf);
+#endif
 
 	/*Shift in and out 1 byte@time*/
 	for (i=0; i < len; i++){
 		/* Write: wait for TX empty (TXS == 1)*/
 		start = get_timer(0);
-		while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) &
+		while (!(readl(&ds->regs->channel[cs].chstat) &
 			 OMAP3_MCSPI_CHSTAT_TXS)) {
 			if (get_timer(start) > SPI_WAIT_TIMEOUT) {
 				printf("SPI TXS timed out, status=0x%08x\n",
-				       readl(&ds->regs->channel[ds->slave.cs].chstat));
+				       readl(&ds->regs->channel[cs].chstat));
 				return -1;
 			}
 		}
 		/* Write the data */
-		unsigned int *tx = &ds->regs->channel[ds->slave.cs].tx;
+		unsigned int *tx = &ds->regs->channel[cs].tx;
+#ifdef CONFIG_DM_SPI
+		if (slave->wordlen > 16)
+#else
 		if (ds->slave.wordlen > 16)
+#endif
 			writel(((u32 *)txp)[i], tx);
+#ifdef CONFIG_DM_SPI
+		else if (slave->wordlen > 8)
+#else
 		else if (ds->slave.wordlen > 8)
+#endif
 			writel(((u16 *)txp)[i], tx);
 		else
 			writel(((u8 *)txp)[i], tx);
 
 		/*Read: wait for RX containing data (RXS == 1)*/
 		start = get_timer(0);
-		while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) &
+		while (!(readl(&ds->regs->channel[cs].chstat) &
 			 OMAP3_MCSPI_CHSTAT_RXS)) {
 			if (get_timer(start) > SPI_WAIT_TIMEOUT) {
 				printf("SPI RXS timed out, status=0x%08x\n",
-				       readl(&ds->regs->channel[ds->slave.cs].chstat));
+				       readl(&ds->regs->channel[cs].chstat));
 				return -1;
 			}
 		}
 		/* Read the data */
-		unsigned int *rx = &ds->regs->channel[ds->slave.cs].rx;
+		unsigned int *rx = &ds->regs->channel[cs].rx;
+#ifdef CONFIG_DM_SPI
+		if (slave->wordlen > 16)
+#else
 		if (ds->slave.wordlen > 16)
+#endif
 			((u32 *)rxp)[i] = readl(rx);
+#ifdef CONFIG_DM_SPI
+		else if (slave->wordlen > 8)
+#else
 		else if (ds->slave.wordlen > 8)
+#endif
 			((u16 *)rxp)[i] = (u16)readl(rx);
 		else
 			((u8 *)rxp)[i] = (u8)readl(rx);
 	}
+
+#ifdef CONFIG_DM_SPI
+	/* Disable the channel */
+	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS);
+#else
 	/* Disable the channel */
-	omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS);
+	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS);
+#endif
 
 	/*if transfer must be terminated disable the channel*/
 	if (flags & SPI_XFER_END) {
 		chconf &= ~OMAP3_MCSPI_CHCONF_FORCE;
-		omap3_spi_write_chconf(ds,chconf);
+#ifdef CONFIG_DM_SPI
+		omap3_spi_write_chconf(dev, chconf);
+#else
+		omap3_spi_write_chconf(ds, chconf);
+#endif
 	}
 
 	return 0;
 }
 
+#ifdef CONFIG_DM_SPI
+int omap3_spi_xfer(struct udevice *dev, unsigned int bitlen,
+		   const void *dout, void *din, unsigned long flags)
+#else
 int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
 	     const void *dout, void *din, unsigned long flags)
+#endif
 {
-	struct omap3_spi_slave *ds = to_omap3_spi(slave);
-	unsigned int	len;
+	struct omap3_spi_slave *ds;
+	unsigned int len, cs;
 	int ret = -1;
+#ifdef CONFIG_DM_SPI
+	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+	struct spi_slave *slave = dev_get_parent_priv(dev);
+
+	ds = dev_get_priv(dev->parent);
+	cs = platdata->cs;
+#else
+	ds = to_omap3_spi(slave);
+	cs = ds->slave.cs;
+#endif
 
+#ifdef CONFIG_DM_SPI
+	if (slave->wordlen < 4 || slave->wordlen > 32) {
+		printf("omap3_spi: invalid wordlen %d\n", slave->wordlen);
+		return -1;
+	}
+
+	if (bitlen % slave->wordlen)
+		return -1;
+
+	len = bitlen / slave->wordlen;
+#else
 	if (ds->slave.wordlen < 4 || ds->slave.wordlen > 32) {
 		printf("omap3_spi: invalid wordlen %d\n", ds->slave.wordlen);
 		return -1;
@@ -415,41 +679,104 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
 		return -1;
 
 	len = bitlen / ds->slave.wordlen;
+#endif
 
 	if (bitlen == 0) {	 /* only change CS */
-		int chconf = readl(&ds->regs->channel[ds->slave.cs].chconf);
+		int chconf = readl(&ds->regs->channel[cs].chconf);
 
 		if (flags & SPI_XFER_BEGIN) {
-			omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN);
+#ifdef CONFIG_DM_SPI
+			omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN);
+#else
+			omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN);
+#endif
 			chconf |= OMAP3_MCSPI_CHCONF_FORCE;
-			omap3_spi_write_chconf(ds,chconf);
+#ifdef CONFIG_DM_SPI
+			omap3_spi_write_chconf(dev, chconf);
+#else
+			omap3_spi_write_chconf(ds, chconf);
+#endif
 		}
 		if (flags & SPI_XFER_END) {
 			chconf &= ~OMAP3_MCSPI_CHCONF_FORCE;
-			omap3_spi_write_chconf(ds,chconf);
-			omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS);
+#ifdef CONFIG_DM_SPI
+			omap3_spi_write_chconf(dev, chconf);
+			omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS);
+#else
+			omap3_spi_write_chconf(ds, chconf);
+			omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS);
+#endif
 		}
 		ret = 0;
 	} else {
+#ifdef CONFIG_DM_SPI
+		if (dout != NULL && din != NULL)
+			ret = omap3_spi_txrx(dev, len, dout, din, flags);
+		else if (dout != NULL)
+			ret = omap3_spi_write(dev, len, dout, flags);
+		else if (din != NULL)
+			ret = omap3_spi_read(dev, len, din, flags);
+#else
 		if (dout != NULL && din != NULL)
 			ret = omap3_spi_txrx(slave, len, dout, din, flags);
 		else if (dout != NULL)
 			ret = omap3_spi_write(slave, len, dout, flags);
 		else if (din != NULL)
 			ret = omap3_spi_read(slave, len, din, flags);
+#endif
 	}
 	return ret;
 }
 
-int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+void spi_cs_activate(struct spi_slave *slave)
 {
-	return 1;
 }
 
-void spi_cs_activate(struct spi_slave *slave)
+void spi_cs_deactivate(struct spi_slave *slave)
 {
 }
 
-void spi_cs_deactivate(struct spi_slave *slave)
+#ifdef CONFIG_DM_SPI
+static int omap3_spi_probe(struct udevice *dev)
 {
+	struct omap3_spi_slave *ds = dev_get_priv(dev);
+
+	ds->regs = (struct mcspi *)dev_get_addr(dev);
+
+	return 0;
 }
+
+static int omap3_spi_set_speed(struct udevice *dev, unsigned int speed)
+{
+	return 0;
+}
+
+static int omap3_spi_set_mode(struct udevice *bus, uint mode)
+{
+	return 0;
+}
+
+
+static const struct dm_spi_ops omap3_spi_ops = {
+	.claim_bus	= omap3_spi_claim_bus,
+	.release_bus	= omap3_spi_release_bus,
+	.xfer		= omap3_spi_xfer,
+	.set_speed	= omap3_spi_set_speed,
+	.set_mode	= omap3_spi_set_mode,
+};
+
+static const struct udevice_id omap3_spi_ids[] = {
+	{ .compatible = "ti,omap2-mcspi" },
+	{ .compatible = "ti,omap4-mcspi" },
+	{ }
+};
+
+U_BOOT_DRIVER(omap3_spi) = {
+	.name   = "omap3_spi",
+	.id     = UCLASS_SPI,
+	.of_match = omap3_spi_ids,
+	.probe = omap3_spi_probe,
+	.ops    = &omap3_spi_ops,
+	.priv_auto_alloc_size = sizeof(struct omap3_spi_slave),
+};
+#endif
diff --git a/drivers/spi/omap3_spi.h b/drivers/spi/omap3_spi.h
index 6a07c6d..a974ca3 100644
--- a/drivers/spi/omap3_spi.h
+++ b/drivers/spi/omap3_spi.h
@@ -88,22 +88,34 @@ struct mcspi {
 #define OMAP3_MCSPI_WAKEUPENABLE_WKEN	BIT(0)
 
 struct omap3_spi_slave {
+#ifndef CONFIG_DM_SPI
 	struct spi_slave slave;
+#endif
 	struct mcspi *regs;
 	unsigned int freq;
 	unsigned int mode;
 };
 
+#ifndef CONFIG_DM_SPI
 static inline struct omap3_spi_slave *to_omap3_spi(struct spi_slave *slave)
 {
 	return container_of(slave, struct omap3_spi_slave, slave);
 }
+#endif
 
+#ifdef CONFIG_DM_SPI
+int omap3_spi_txrx(struct udevice *dev, unsigned int len, const void *txp,
+			void *rxp, unsigned long flags);
+int omap3_spi_write(struct udevice *dev, unsigned int len, const void *txp,
+		    unsigned long flags);
+int omap3_spi_read(struct udevice *dev, unsigned int len, void *rxp,
+		   unsigned long flags);
+#else
 int omap3_spi_txrx(struct spi_slave *slave, unsigned int len, const void *txp,
 			void *rxp, unsigned long flags);
 int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp,
 		    unsigned long flags);
 int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
 		   unsigned long flags);
-
+#endif
 #endif /* _OMAP3_SPI_H_ */
-- 
2.5.0

[U-Boot] [PATCH 4/4] spi: omap3: Convert fully to DM_SPI

[Christophe Ricard]

For several reasons:
- code clarity
- DM trends in u-boot
...

It is better to make omap3_spi driver 100% DM_SPI based.

Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
---

 drivers/spi/omap3_spi.c | 474 +++++++++++-------------------------------------
 drivers/spi/omap3_spi.h | 121 ------------
 2 files changed, 102 insertions(+), 493 deletions(-)
 delete mode 100644 drivers/spi/omap3_spi.h

diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 09fb1ef..8ea2cc5 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -22,22 +22,93 @@
 #include <spi.h>
 #include <malloc.h>
 #include <asm/io.h>
-#include "omap3_spi.h"
+
+#if defined(CONFIG_AM33XX) || defined(CONFIG_AM43XX)
+#define OMAP3_MCSPI1_BASE	0x48030100
+#define OMAP3_MCSPI2_BASE	0x481A0100
+#else
+#define OMAP3_MCSPI1_BASE	0x48098000
+#define OMAP3_MCSPI2_BASE	0x4809A000
+#define OMAP3_MCSPI3_BASE	0x480B8000
+#define OMAP3_MCSPI4_BASE	0x480BA000
+#endif
+
+#define OMAP3_MCSPI_MAX_FREQ	48000000
+
+/* OMAP3 McSPI registers */
+struct mcspi_channel {
+	unsigned int chconf;		/* 0x2C, 0x40, 0x54, 0x68 */
+	unsigned int chstat;		/* 0x30, 0x44, 0x58, 0x6C */
+	unsigned int chctrl;		/* 0x34, 0x48, 0x5C, 0x70 */
+	unsigned int tx;		/* 0x38, 0x4C, 0x60, 0x74 */
+	unsigned int rx;		/* 0x3C, 0x50, 0x64, 0x78 */
+};
+
+struct mcspi {
+	unsigned char res1[0x10];
+	unsigned int sysconfig;		/* 0x10 */
+	unsigned int sysstatus;		/* 0x14 */
+	unsigned int irqstatus;		/* 0x18 */
+	unsigned int irqenable;		/* 0x1C */
+	unsigned int wakeupenable;	/* 0x20 */
+	unsigned int syst;		/* 0x24 */
+	unsigned int modulctrl;		/* 0x28 */
+	struct mcspi_channel channel[4]; /* channel0: 0x2C - 0x3C, bus 0 & 1 & 2 & 3 */
+					/* channel1: 0x40 - 0x50, bus 0 & 1 */
+					/* channel2: 0x54 - 0x64, bus 0 & 1 */
+					/* channel3: 0x68 - 0x78, bus 0 */
+};
+
+/* per-register bitmasks */
+#define OMAP3_MCSPI_SYSCONFIG_SMARTIDLE (2 << 3)
+#define OMAP3_MCSPI_SYSCONFIG_ENAWAKEUP (1 << 2)
+#define OMAP3_MCSPI_SYSCONFIG_AUTOIDLE	(1 << 0)
+#define OMAP3_MCSPI_SYSCONFIG_SOFTRESET (1 << 1)
+
+#define OMAP3_MCSPI_SYSSTATUS_RESETDONE (1 << 0)
+
+#define OMAP3_MCSPI_MODULCTRL_SINGLE	(1 << 0)
+#define OMAP3_MCSPI_MODULCTRL_MS	(1 << 2)
+#define OMAP3_MCSPI_MODULCTRL_STEST	(1 << 3)
+
+#define OMAP3_MCSPI_CHCONF_PHA		(1 << 0)
+#define OMAP3_MCSPI_CHCONF_POL		(1 << 1)
+#define OMAP3_MCSPI_CHCONF_CLKD_MASK	(0x0f << 2)
+#define OMAP3_MCSPI_CHCONF_EPOL		(1 << 6)
+#define OMAP3_MCSPI_CHCONF_WL_MASK	(0x1f << 7)
+#define OMAP3_MCSPI_CHCONF_TRM_RX_ONLY	(0x01 << 12)
+#define OMAP3_MCSPI_CHCONF_TRM_TX_ONLY	(0x02 << 12)
+#define OMAP3_MCSPI_CHCONF_TRM_MASK	(0x03 << 12)
+#define OMAP3_MCSPI_CHCONF_DMAW		(1 << 14)
+#define OMAP3_MCSPI_CHCONF_DMAR		(1 << 15)
+#define OMAP3_MCSPI_CHCONF_DPE0		(1 << 16)
+#define OMAP3_MCSPI_CHCONF_DPE1		(1 << 17)
+#define OMAP3_MCSPI_CHCONF_IS		(1 << 18)
+#define OMAP3_MCSPI_CHCONF_TURBO	(1 << 19)
+#define OMAP3_MCSPI_CHCONF_FORCE	(1 << 20)
+
+#define OMAP3_MCSPI_CHSTAT_RXS		(1 << 0)
+#define OMAP3_MCSPI_CHSTAT_TXS		(1 << 1)
+#define OMAP3_MCSPI_CHSTAT_EOT		(1 << 2)
+
+#define OMAP3_MCSPI_CHCTRL_EN		(1 << 0)
+#define OMAP3_MCSPI_CHCTRL_DIS		(0 << 0)
+
+#define OMAP3_MCSPI_WAKEUPENABLE_WKEN	(1 << 0)
+
+struct omap3_spi_slave {
+	struct mcspi *regs;
+	unsigned int freq;
+	unsigned int mode;
+};
 
 #define SPI_WAIT_TIMEOUT 10
 
-#ifdef CONFIG_DM_SPI
 static void spi_reset(struct udevice *dev)
-#else
-static void spi_reset(struct omap3_spi_slave *ds)
-#endif
 {
 	unsigned int tmp;
-#ifdef CONFIG_DM_SPI
 	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
 
-#endif
-
 	writel(OMAP3_MCSPI_SYSCONFIG_SOFTRESET, &ds->regs->sysconfig);
 	do {
 		tmp = readl(&ds->regs->sysstatus);
@@ -51,161 +122,37 @@ static void spi_reset(struct omap3_spi_slave *ds)
 	writel(OMAP3_MCSPI_WAKEUPENABLE_WKEN, &ds->regs->wakeupenable);
 }
 
-#ifdef CONFIG_DM_SPI
 static void omap3_spi_write_chconf(struct udevice *dev, int val)
-#else
-static void omap3_spi_write_chconf(struct omap3_spi_slave *ds, int val)
-#endif
 {
-	unsigned int cs;
-#ifdef CONFIG_DM_SPI
 	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
 	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
-
-
-	cs = platdata->cs;
-#else
-	cs = ds->slave.cs;
-#endif
+	unsigned int cs = platdata->cs;
 
 	writel(val, &ds->regs->channel[cs].chconf);
 	/* Flash post writes to make immediate effect */
 	readl(&ds->regs->channel[cs].chconf);
 }
 
-#ifdef CONFIG_DM_SPI
 static void omap3_spi_set_enable(struct udevice *dev, int enable)
-#else
-static void omap3_spi_set_enable(struct omap3_spi_slave *ds, int enable)
-#endif
 {
-	unsigned int cs;
-#ifdef CONFIG_DM_SPI
 	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
 	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
-
-	cs = platdata->cs;
-#else
-	cs = ds->slave.cs;
-#endif
+	unsigned int cs = platdata->cs;
 
 	writel(enable, &ds->regs->channel[cs].chctrl);
 	/* Flash post writes to make immediate effect */
 	readl(&ds->regs->channel[cs].chctrl);
 }
 
-#ifndef CONFIG_DM_SPI
-void spi_init()
-{
-	/* do nothing */
-}
-
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
-				  unsigned int max_hz, unsigned int mode)
-{
-	struct omap3_spi_slave	*ds;
-	struct mcspi *regs;
-
-	/*
-	 * OMAP3 McSPI (MultiChannel SPI) has 4 busses (modules)
-	 * with different number of chip selects (CS, channels):
-	 * McSPI1 has 4 CS (bus 0, cs 0 - 3)
-	 * McSPI2 has 2 CS (bus 1, cs 0 - 1)
-	 * McSPI3 has 2 CS (bus 2, cs 0 - 1)
-	 * McSPI4 has 1 CS (bus 3, cs 0)
-	 */
-
-	switch (bus) {
-	case 0:
-		regs = (struct mcspi *)OMAP3_MCSPI1_BASE;
-		break;
-#ifdef OMAP3_MCSPI2_BASE
-	case 1:
-		regs = (struct mcspi *)OMAP3_MCSPI2_BASE;
-		break;
-#endif
-#ifdef OMAP3_MCSPI3_BASE
-	case 2:
-		regs = (struct mcspi *)OMAP3_MCSPI3_BASE;
-		break;
-#endif
-#ifdef OMAP3_MCSPI4_BASE
-	case 3:
-		regs = (struct mcspi *)OMAP3_MCSPI4_BASE;
-		break;
-#endif
-	default:
-		printf("SPI error: unsupported bus %i. \
-			Supported busses 0 - 3\n", bus);
-		return NULL;
-	}
-
-	if (((bus == 0) && (cs > 3)) ||
-			((bus == 1) && (cs > 1)) ||
-			((bus == 2) && (cs > 1)) ||
-			((bus == 3) && (cs > 0))) {
-		printf("SPI error: unsupported chip select %i \
-			on bus %i\n", cs, bus);
-		return NULL;
-	}
-
-	if (max_hz > OMAP3_MCSPI_MAX_FREQ) {
-		printf("SPI error: unsupported frequency %i Hz. \
-			Max frequency is 48 Mhz\n", max_hz);
-		return NULL;
-	}
-
-	if (mode > SPI_MODE_3) {
-		printf("SPI error: unsupported SPI mode %i\n", mode);
-		return NULL;
-	}
-
-	ds = spi_alloc_slave(struct omap3_spi_slave, bus, cs);
-	if (!ds) {
-		printf("SPI error: malloc of SPI structure failed\n");
-		return NULL;
-	}
-
-	ds->regs = regs;
-	ds->freq = max_hz;
-	ds->mode = mode;
-
-	return &ds->slave;
-}
-
-void spi_free_slave(struct spi_slave *slave)
-{
-	struct omap3_spi_slave *ds = to_omap3_spi(slave);
-
-	free(ds);
-}
-
-int spi_cs_is_valid(unsigned int bus, unsigned int cs)
-{
-	return 1;
-}
-#endif
-
-#ifdef CONFIG_DM_SPI
 static int omap3_spi_claim_bus(struct udevice *dev)
-#else
-int spi_claim_bus(struct spi_slave *slave)
-#endif
 {
-	unsigned int cs;
-	struct omap3_spi_slave *ds;
 	unsigned int conf, div = 0;
-#ifdef CONFIG_DM_SPI
 	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
 	struct spi_slave *slave = dev_get_parent_priv(dev);
+	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+	unsigned int cs = platdata->cs;
 
-	ds = dev_get_priv(dev->parent);
-	cs = platdata->cs;
 	ds->freq = slave->max_hz;
-#else
-	ds = to_omap3_spi(slave);
-	cs = ds->slave.cs;
-#endif
 
 	/* McSPI global module configuration */
 
@@ -213,11 +160,7 @@ int spi_claim_bus(struct spi_slave *slave)
 	 * setup when switching from (reset default) slave mode
 	 * to single-channel master mode
 	 */
-#ifdef CONFIG_DM_SPI
 	spi_reset(dev);
-#else
-	spi_reset(ds);
-#endif
 	conf = readl(&ds->regs->modulctrl);
 	conf &= ~(OMAP3_MCSPI_MODULCTRL_STEST | OMAP3_MCSPI_MODULCTRL_MS);
 	conf |= OMAP3_MCSPI_MODULCTRL_SINGLE;
@@ -276,83 +219,38 @@ int spi_claim_bus(struct spi_slave *slave)
 	/* Transmit & receive mode */
 	conf &= ~OMAP3_MCSPI_CHCONF_TRM_MASK;
 
-#ifdef CONFIG_DM_SPI
 	omap3_spi_write_chconf(dev, conf);
-#else
-	omap3_spi_write_chconf(ds,conf);
-#endif
 
 	return 0;
 }
 
-#ifdef CONFIG_DM_SPI
 int omap3_spi_release_bus(struct udevice *dev)
-#else
-void spi_release_bus(struct spi_slave *slave)
-#endif
 {
-#ifndef CONFIG_DM_SPI
-	struct omap3_spi_slave *ds = to_omap3_spi(slave);
-#endif
 	/* Reset the SPI hardware */
-#ifdef CONFIG_DM_SPI
 	spi_reset(dev);
-#else
-	spi_reset(ds);
-#endif
 
-#ifdef CONFIG_DM_SPI
 	return 0;
-#endif
 }
 
-#ifdef CONFIG_DM_SPI
 int omap3_spi_write(struct udevice *dev, unsigned int len, const void *txp,
 		    unsigned long flags)
-#else
-int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp,
-		    unsigned long flags)
-#endif
 {
-	struct omap3_spi_slave *ds;
 	int i, chconf;
 	ulong start;
-	unsigned int cs;
-#ifdef CONFIG_DM_SPI
 	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
 	struct spi_slave *slave = dev_get_parent_priv(dev);
-
-
-	ds = dev_get_priv(dev->parent);
-	cs = platdata->cs;
-#else
-	ds = to_omap3_spi(slave);
-	cs = ds->slave.cs;
-#endif
+	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+	unsigned int cs = platdata->cs;
 
 	chconf = readl(&ds->regs->channel[cs].chconf);
 
-#ifdef CONFIG_DM_SPI
 	/* Enable the channel */
 	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN);
-#else
-	/* Enable the channel */
-	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN);
-#endif
-
 	chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK);
-#ifdef CONFIG_DM_SPI
 	chconf |= (slave->wordlen - 1) << 7;
-#else
-	chconf |= (ds->slave.wordlen - 1) << 7;
-#endif
 	chconf |= OMAP3_MCSPI_CHCONF_TRM_TX_ONLY;
 	chconf |= OMAP3_MCSPI_CHCONF_FORCE;
-#ifdef CONFIG_DM_SPI
 	omap3_spi_write_chconf(dev, chconf);
-#else
-	omap3_spi_write_chconf(ds, chconf);
-#endif
 
 	for (i = 0; i < len; i++) {
 		/* wait till TX register is empty (TXS == 1) */
@@ -368,17 +266,9 @@ int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp,
 
 		/* Write the data */
 		unsigned int *tx = &ds->regs->channel[cs].tx;
-#ifdef CONFIG_DM_SPI
 		if (slave->wordlen > 16)
-#else
-		if (ds->slave.wordlen > 16)
-#endif
 			writel(((u32 *)txp)[i], tx);
-#ifdef CONFIG_DM_SPI
 		else if (slave->wordlen > 8)
-#else
-		else if (ds->slave.wordlen > 8)
-#endif
 			writel(((u16 *)txp)[i], tx);
 		else
 			writel(((u8 *)txp)[i], tx);
@@ -390,73 +280,38 @@ int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp,
 			 (OMAP3_MCSPI_CHSTAT_EOT | OMAP3_MCSPI_CHSTAT_TXS))
 		;
 
-#ifdef CONFIG_DM_SPI
 	/* Disable the channel otherwise the next immediate RX will get affected */
 	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS);
-#else
-	/* Disable the channel otherwise the next immediate RX will get affected */
-	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS);
-#endif
 
 	if (flags & SPI_XFER_END) {
 
 		chconf &= ~OMAP3_MCSPI_CHCONF_FORCE;
-#ifdef CONFIG_DM_SPI
 		omap3_spi_write_chconf(dev, chconf);
-#else
-		omap3_spi_write_chconf(ds, chconf);
-#endif
 	}
 
 	return 0;
 }
 
-#ifdef CONFIG_DM_SPI
-int omap3_spi_read(struct udevice *dev, unsigned int len, void *rxp,
-		   unsigned long flags)
-#else
-int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
-		   unsigned long flags)
-#endif
+static int omap3_spi_read(struct udevice *dev, unsigned int len, void *rxp,
+			  unsigned long flags)
 {
-	struct omap3_spi_slave *ds;
-	int i, chconf;
-	ulong start;
-	unsigned int cs;
-#ifdef CONFIG_DM_SPI
 	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
 	struct spi_slave *slave = dev_get_parent_priv(dev);
+	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+	int i, chconf;
+	ulong start;
+	unsigned int cs = platdata->cs;
 
-
-	ds = dev_get_priv(dev->parent);
-	cs = platdata->cs;
-#else
-	ds = to_omap3_spi(slave);
-	cs = ds->slave.cs;
-#endif
 	chconf = readl(&ds->regs->channel[cs].chconf);
 
-#ifdef CONFIG_DM_SPI
 	/* Enable the channel */
 	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN);
-#else
-	/* Enable the channel */
-	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN);
-#endif
 
 	chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK);
-#ifdef CONFIG_DM_SPI
 	chconf |= (slave->wordlen - 1) << 7;
-#else
-	chconf |= (ds->slave.wordlen - 1) << 7;
-#endif
 	chconf |= OMAP3_MCSPI_CHCONF_TRM_RX_ONLY;
 	chconf |= OMAP3_MCSPI_CHCONF_FORCE;
-#ifdef CONFIG_DM_SPI
 	omap3_spi_write_chconf(dev, chconf);
-#else
-	omap3_spi_write_chconf(ds, chconf);
-#endif
 
 	writel(0, &ds->regs->channel[cs].tx);
 
@@ -473,25 +328,13 @@ int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
 		}
 		/* Disable the channel to prevent furher receiving */
 		if(i == (len - 1))
-#ifdef CONFIG_DM_SPI
 			omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS);
-#else
-			omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS);
-#endif
 
 		/* Read the data */
 		unsigned int *rx = &ds->regs->channel[cs].rx;
-#ifdef CONFIG_DM_SPI
 		if (slave->wordlen > 16)
-#else
-		if (ds->slave.wordlen > 16)
-#endif
 			((u32 *)rxp)[i] = readl(rx);
-#ifdef CONFIG_DM_SPI
 		else if (slave->wordlen > 8)
-#else
-		else if (ds->slave.wordlen > 8)
-#endif
 			((u16 *)rxp)[i] = (u16)readl(rx);
 		else
 			((u8 *)rxp)[i] = (u8)readl(rx);
@@ -499,65 +342,34 @@ int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
 
 	if (flags & SPI_XFER_END) {
 		chconf &= ~OMAP3_MCSPI_CHCONF_FORCE;
-#ifdef CONFIG_DM_SPI
 		omap3_spi_write_chconf(dev, chconf);
-#else
-		omap3_spi_write_chconf(ds, chconf);
-#endif
 	}
 
 	return 0;
 }
 
-#ifdef CONFIG_DM_SPI
 /*McSPI Transmit Receive Mode*/
-int omap3_spi_txrx(struct udevice *dev, unsigned int len,
-		   const void *txp, void *rxp, unsigned long flags)
-#else
-/*McSPI Transmit Receive Mode*/
-int omap3_spi_txrx(struct spi_slave *slave, unsigned int len,
-		   const void *txp, void *rxp, unsigned long flags)
-#endif
+static int omap3_spi_txrx(struct udevice *dev, unsigned int len,
+			  const void *txp, void *rxp, unsigned long flags)
 {
-	struct omap3_spi_slave *ds;
+	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+	struct spi_slave *slave = dev_get_parent_priv(dev);
+	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
 	ulong start;
 	int chconf;
 	int i=0;
-	unsigned int cs;
-#ifdef CONFIG_DM_SPI
-	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
-	struct spi_slave *slave = dev_get_parent_priv(dev);
-
+	unsigned int cs = platdata->cs;
 
-	ds = dev_get_priv(dev->parent);
-	cs = platdata->cs;
-#else
-	ds = to_omap3_spi(slave);
-	cs = ds->slave.cs;
-#endif
 	chconf = readl(&ds->regs->channel[cs].chconf);
 
-#ifdef CONFIG_DM_SPI
 	/*Enable SPI channel*/
 	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN);
-#else
-	/*Enable SPI channel*/
-	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN);
-#endif
 
 	/*set TRANSMIT-RECEIVE Mode*/
 	chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK);
-#ifdef CONFIG_DM_SPI
 	chconf |= (slave->wordlen - 1) << 7;
-#else
-	chconf |= (ds->slave.wordlen - 1) << 7;
-#endif
 	chconf |= OMAP3_MCSPI_CHCONF_FORCE;
-#ifdef CONFIG_DM_SPI
 	omap3_spi_write_chconf(dev, chconf);
-#else
-	omap3_spi_write_chconf(ds, chconf);
-#endif
 
 	/*Shift in and out 1 byte@time*/
 	for (i=0; i < len; i++){
@@ -573,17 +385,9 @@ int omap3_spi_txrx(struct spi_slave *slave, unsigned int len,
 		}
 		/* Write the data */
 		unsigned int *tx = &ds->regs->channel[cs].tx;
-#ifdef CONFIG_DM_SPI
 		if (slave->wordlen > 16)
-#else
-		if (ds->slave.wordlen > 16)
-#endif
 			writel(((u32 *)txp)[i], tx);
-#ifdef CONFIG_DM_SPI
 		else if (slave->wordlen > 8)
-#else
-		else if (ds->slave.wordlen > 8)
-#endif
 			writel(((u16 *)txp)[i], tx);
 		else
 			writel(((u8 *)txp)[i], tx);
@@ -600,66 +404,35 @@ int omap3_spi_txrx(struct spi_slave *slave, unsigned int len,
 		}
 		/* Read the data */
 		unsigned int *rx = &ds->regs->channel[cs].rx;
-#ifdef CONFIG_DM_SPI
 		if (slave->wordlen > 16)
-#else
-		if (ds->slave.wordlen > 16)
-#endif
 			((u32 *)rxp)[i] = readl(rx);
-#ifdef CONFIG_DM_SPI
 		else if (slave->wordlen > 8)
-#else
-		else if (ds->slave.wordlen > 8)
-#endif
 			((u16 *)rxp)[i] = (u16)readl(rx);
 		else
 			((u8 *)rxp)[i] = (u8)readl(rx);
 	}
 
-#ifdef CONFIG_DM_SPI
 	/* Disable the channel */
 	omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS);
-#else
-	/* Disable the channel */
-	omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS);
-#endif
 
 	/*if transfer must be terminated disable the channel*/
 	if (flags & SPI_XFER_END) {
 		chconf &= ~OMAP3_MCSPI_CHCONF_FORCE;
-#ifdef CONFIG_DM_SPI
 		omap3_spi_write_chconf(dev, chconf);
-#else
-		omap3_spi_write_chconf(ds, chconf);
-#endif
 	}
 
 	return 0;
 }
 
-#ifdef CONFIG_DM_SPI
-int omap3_spi_xfer(struct udevice *dev, unsigned int bitlen,
-		   const void *dout, void *din, unsigned long flags)
-#else
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
-	     const void *dout, void *din, unsigned long flags)
-#endif
+static int omap3_spi_xfer(struct udevice *dev, unsigned int bitlen,
+			  const void *dout, void *din, unsigned long flags)
 {
-	struct omap3_spi_slave *ds;
-	unsigned int len, cs;
-	int ret = -1;
-#ifdef CONFIG_DM_SPI
 	struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
 	struct spi_slave *slave = dev_get_parent_priv(dev);
+	struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+	unsigned int len, cs = platdata->cs;
+	int ret = -1;
 
-	ds = dev_get_priv(dev->parent);
-	cs = platdata->cs;
-#else
-	ds = to_omap3_spi(slave);
-	cs = ds->slave.cs;
-#endif
-
-#ifdef CONFIG_DM_SPI
 	if (slave->wordlen < 4 || slave->wordlen > 32) {
 		printf("omap3_spi: invalid wordlen %d\n", slave->wordlen);
 		return -1;
@@ -669,74 +442,32 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
 		return -1;
 
 	len = bitlen / slave->wordlen;
-#else
-	if (ds->slave.wordlen < 4 || ds->slave.wordlen > 32) {
-		printf("omap3_spi: invalid wordlen %d\n", ds->slave.wordlen);
-		return -1;
-	}
-
-	if (bitlen % ds->slave.wordlen)
-		return -1;
-
-	len = bitlen / ds->slave.wordlen;
-#endif
 
 	if (bitlen == 0) {	 /* only change CS */
 		int chconf = readl(&ds->regs->channel[cs].chconf);
 
 		if (flags & SPI_XFER_BEGIN) {
-#ifdef CONFIG_DM_SPI
 			omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN);
-#else
-			omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN);
-#endif
 			chconf |= OMAP3_MCSPI_CHCONF_FORCE;
-#ifdef CONFIG_DM_SPI
 			omap3_spi_write_chconf(dev, chconf);
-#else
-			omap3_spi_write_chconf(ds, chconf);
-#endif
 		}
 		if (flags & SPI_XFER_END) {
 			chconf &= ~OMAP3_MCSPI_CHCONF_FORCE;
-#ifdef CONFIG_DM_SPI
 			omap3_spi_write_chconf(dev, chconf);
 			omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS);
-#else
-			omap3_spi_write_chconf(ds, chconf);
-			omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS);
-#endif
 		}
 		ret = 0;
 	} else {
-#ifdef CONFIG_DM_SPI
 		if (dout != NULL && din != NULL)
 			ret = omap3_spi_txrx(dev, len, dout, din, flags);
 		else if (dout != NULL)
 			ret = omap3_spi_write(dev, len, dout, flags);
 		else if (din != NULL)
 			ret = omap3_spi_read(dev, len, din, flags);
-#else
-		if (dout != NULL && din != NULL)
-			ret = omap3_spi_txrx(slave, len, dout, din, flags);
-		else if (dout != NULL)
-			ret = omap3_spi_write(slave, len, dout, flags);
-		else if (din != NULL)
-			ret = omap3_spi_read(slave, len, din, flags);
-#endif
 	}
 	return ret;
 }
 
-void spi_cs_activate(struct spi_slave *slave)
-{
-}
-
-void spi_cs_deactivate(struct spi_slave *slave)
-{
-}
-
-#ifdef CONFIG_DM_SPI
 static int omap3_spi_probe(struct udevice *dev)
 {
 	struct omap3_spi_slave *ds = dev_get_priv(dev);
@@ -779,4 +510,3 @@ U_BOOT_DRIVER(omap3_spi) = {
 	.ops    = &omap3_spi_ops,
 	.priv_auto_alloc_size = sizeof(struct omap3_spi_slave),
 };
-#endif
diff --git a/drivers/spi/omap3_spi.h b/drivers/spi/omap3_spi.h
deleted file mode 100644
index a974ca3..0000000
--- a/drivers/spi/omap3_spi.h
+++ /dev/null
@@ -1,121 +0,0 @@
-/*
- * Register definitions for the OMAP3 McSPI Controller
- *
- * Copyright (C) 2010 Dirk Behme <dirk.behme@googlemail.com>
- *
- * Parts taken from linux/drivers/spi/omap2_mcspi.c
- * Copyright (C) 2005, 2006 Nokia Corporation
- *
- * Modified by Ruslan Araslanov <ruslan.araslanov@vitecmm.com>
- *
- * SPDX-License-Identifier:	GPL-2.0+
- */
-
-#ifndef _OMAP3_SPI_H_
-#define _OMAP3_SPI_H_
-
-#if defined(CONFIG_AM33XX) || defined(CONFIG_AM43XX)
-#define OMAP3_MCSPI1_BASE	0x48030100
-#define OMAP3_MCSPI2_BASE	0x481A0100
-#else
-#define OMAP3_MCSPI1_BASE	0x48098000
-#define OMAP3_MCSPI2_BASE	0x4809A000
-#define OMAP3_MCSPI3_BASE	0x480B8000
-#define OMAP3_MCSPI4_BASE	0x480BA000
-#endif
-
-#define OMAP3_MCSPI_MAX_FREQ	48000000
-
-/* OMAP3 McSPI registers */
-struct mcspi_channel {
-	unsigned int chconf;		/* 0x2C, 0x40, 0x54, 0x68 */
-	unsigned int chstat;		/* 0x30, 0x44, 0x58, 0x6C */
-	unsigned int chctrl;		/* 0x34, 0x48, 0x5C, 0x70 */
-	unsigned int tx;		/* 0x38, 0x4C, 0x60, 0x74 */
-	unsigned int rx;		/* 0x3C, 0x50, 0x64, 0x78 */
-};
-
-struct mcspi {
-	unsigned char res1[0x10];
-	unsigned int sysconfig;		/* 0x10 */
-	unsigned int sysstatus;		/* 0x14 */
-	unsigned int irqstatus;		/* 0x18 */
-	unsigned int irqenable;		/* 0x1C */
-	unsigned int wakeupenable;	/* 0x20 */
-	unsigned int syst;		/* 0x24 */
-	unsigned int modulctrl;		/* 0x28 */
-	struct mcspi_channel channel[4]; /* channel0: 0x2C - 0x3C, bus 0 & 1 & 2 & 3 */
-					/* channel1: 0x40 - 0x50, bus 0 & 1 */
-					/* channel2: 0x54 - 0x64, bus 0 & 1 */
-					/* channel3: 0x68 - 0x78, bus 0 */
-};
-
-/* per-register bitmasks */
-#define OMAP3_MCSPI_SYSCONFIG_SMARTIDLE (2 << 3)
-#define OMAP3_MCSPI_SYSCONFIG_ENAWAKEUP BIT(2)
-#define OMAP3_MCSPI_SYSCONFIG_AUTOIDLE	BIT(0)
-#define OMAP3_MCSPI_SYSCONFIG_SOFTRESET BIT(1)
-
-#define OMAP3_MCSPI_SYSSTATUS_RESETDONE BIT(0)
-
-#define OMAP3_MCSPI_MODULCTRL_SINGLE	BIT(0)
-#define OMAP3_MCSPI_MODULCTRL_MS	BIT(2)
-#define OMAP3_MCSPI_MODULCTRL_STEST	BIT(3)
-
-#define OMAP3_MCSPI_CHCONF_PHA		BIT(0)
-#define OMAP3_MCSPI_CHCONF_POL		BIT(1)
-#define OMAP3_MCSPI_CHCONF_CLKD_MASK	GENMASK(5, 2)
-#define OMAP3_MCSPI_CHCONF_EPOL		BIT(6)
-#define OMAP3_MCSPI_CHCONF_WL_MASK	GENMASK(11, 7)
-#define OMAP3_MCSPI_CHCONF_TRM_RX_ONLY	BIT(12)
-#define OMAP3_MCSPI_CHCONF_TRM_TX_ONLY	BIT(13)
-#define OMAP3_MCSPI_CHCONF_TRM_MASK	GENMASK(13, 12)
-#define OMAP3_MCSPI_CHCONF_DMAW		BIT(14)
-#define OMAP3_MCSPI_CHCONF_DMAR		BIT(15)
-#define OMAP3_MCSPI_CHCONF_DPE0		BIT(16)
-#define OMAP3_MCSPI_CHCONF_DPE1		BIT(17)
-#define OMAP3_MCSPI_CHCONF_IS		BIT(18)
-#define OMAP3_MCSPI_CHCONF_TURBO	BIT(19)
-#define OMAP3_MCSPI_CHCONF_FORCE	BIT(20)
-
-#define OMAP3_MCSPI_CHSTAT_RXS		BIT(0)
-#define OMAP3_MCSPI_CHSTAT_TXS		BIT(1)
-#define OMAP3_MCSPI_CHSTAT_EOT		BIT(2)
-
-#define OMAP3_MCSPI_CHCTRL_EN		BIT(0)
-#define OMAP3_MCSPI_CHCTRL_DIS		(0 << 0)
-
-#define OMAP3_MCSPI_WAKEUPENABLE_WKEN	BIT(0)
-
-struct omap3_spi_slave {
-#ifndef CONFIG_DM_SPI
-	struct spi_slave slave;
-#endif
-	struct mcspi *regs;
-	unsigned int freq;
-	unsigned int mode;
-};
-
-#ifndef CONFIG_DM_SPI
-static inline struct omap3_spi_slave *to_omap3_spi(struct spi_slave *slave)
-{
-	return container_of(slave, struct omap3_spi_slave, slave);
-}
-#endif
-
-#ifdef CONFIG_DM_SPI
-int omap3_spi_txrx(struct udevice *dev, unsigned int len, const void *txp,
-			void *rxp, unsigned long flags);
-int omap3_spi_write(struct udevice *dev, unsigned int len, const void *txp,
-		    unsigned long flags);
-int omap3_spi_read(struct udevice *dev, unsigned int len, void *rxp,
-		   unsigned long flags);
-#else
-int omap3_spi_txrx(struct spi_slave *slave, unsigned int len, const void *txp,
-			void *rxp, unsigned long flags);
-int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp,
-		    unsigned long flags);
-int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
-		   unsigned long flags);
-#endif
-#endif /* _OMAP3_SPI_H_ */
-- 
2.5.0

[U-Boot] [PATCH 1/4] spi: omap3: Remove unused variable irqstatus in omap3_spi_txrx

[Simon Glass]

On 17 January 2016 at 03:56, Christophe Ricard
<christophe.ricard@gmail.com> wrote:
> Remove unused variable irqstatus in omap3_spi_txrx
>
> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
> ---
>
>  drivers/spi/omap3_spi.c | 2 --
>  1 file changed, 2 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 2/4] spi: spi-uclass: Set slave wordlen with SPI_DEFAULT_WORDLEN

[Simon Glass]

On 17 January 2016 at 03:56, Christophe Ricard
<christophe.ricard@gmail.com> wrote:
> In some case wordlen may not be set. Use SPI_DEFAULT_WORDLEN as default.
>
> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
> ---
>
>  drivers/spi/spi-uclass.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Simon Glass]

+Mugunthan, Tom

On 17 January 2016 at 03:56, Christophe Ricard
<christophe.ricard@gmail.com> wrote:
> Convert omap3_spi driver to DM and keep compatibility with previous
> mode.
>
> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
> ---
>
>  drivers/spi/Kconfig     |   6 +
>  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>  drivers/spi/omap3_spi.h |  14 +-
>  3 files changed, 402 insertions(+), 57 deletions(-)

This is a pretty painful conversion, with lots of #ifdefs. I think it
would be possible to use a common pointer type and reduce this.

But perhaps it does not matter - how long must we be in the state of
supporting legacy SPI? Can we convert all TI boards to driver model?

Regards,
Simon

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Tom Rini]

On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> +Mugunthan, Tom
> 
> On 17 January 2016 at 03:56, Christophe Ricard
> <christophe.ricard@gmail.com> wrote:
> > Convert omap3_spi driver to DM and keep compatibility with previous
> > mode.
> >
> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
> > ---
> >
> >  drivers/spi/Kconfig     |   6 +
> >  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
> >  drivers/spi/omap3_spi.h |  14 +-
> >  3 files changed, 402 insertions(+), 57 deletions(-)
> 
> This is a pretty painful conversion, with lots of #ifdefs. I think it
> would be possible to use a common pointer type and reduce this.
> 
> But perhaps it does not matter - how long must we be in the state of
> supporting legacy SPI? Can we convert all TI boards to driver model?

We _really_ need some way to support more than one board per binary
before we can move everything to DM only.

I think we can kind of do this today if we stick to using platform data
for everything that's board-specific rather than SoC-defined.  What we
talked about at ELCE was auto-generating the pdata from the device tree,
I think.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160121/4150bd37/attachment.sig>

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Simon Glass]

+Hans

Hi Tom,

On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>> +Mugunthan, Tom
>>
>> On 17 January 2016 at 03:56, Christophe Ricard
>> <christophe.ricard@gmail.com> wrote:
>> > Convert omap3_spi driver to DM and keep compatibility with previous
>> > mode.
>> >
>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>> > ---
>> >
>> >  drivers/spi/Kconfig     |   6 +
>> >  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>> >  drivers/spi/omap3_spi.h |  14 +-
>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>>
>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>> would be possible to use a common pointer type and reduce this.
>>
>> But perhaps it does not matter - how long must we be in the state of
>> supporting legacy SPI? Can we convert all TI boards to driver model?
>
> We _really_ need some way to support more than one board per binary
> before we can move everything to DM only.
>
> I think we can kind of do this today if we stick to using platform data
> for everything that's board-specific rather than SoC-defined.  What we
> talked about at ELCE was auto-generating the pdata from the device tree,
> I think.

We discussed this on IRC but since that doesn't exist as far as the
mailing list is concerned...

The current plan is:

- Adjust build system to optionally build a u-boot.img in FIT format
that includes the U-Boot binary and >1 device tree files
- Adjust SPL to load this
- Add a way for SPL to determine which device tree to select (by
calling a board-specific function)
- Have SPL pass this selected device tree to U-Boot when it starts

Thus we should be able to support more than one board with a single
U-Boot image. Of course this is not a perfect solution (e.g. it is
inefficient since the DTs are likely to be largely the same) but it
should be a good first step.

I'm going to try this out with sunxi initially and plan to get some
patches out by the end of the week.

Regards,
Simon

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Peng Fan]

Hi Simon,

On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>+Hans
>
>Hi Tom,
>
>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>> +Mugunthan, Tom
>>>
>>> On 17 January 2016 at 03:56, Christophe Ricard
>>> <christophe.ricard@gmail.com> wrote:
>>> > Convert omap3_spi driver to DM and keep compatibility with previous
>>> > mode.
>>> >
>>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>>> > ---
>>> >
>>> >  drivers/spi/Kconfig     |   6 +
>>> >  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>>> >  drivers/spi/omap3_spi.h |  14 +-
>>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>>>
>>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>>> would be possible to use a common pointer type and reduce this.
>>>
>>> But perhaps it does not matter - how long must we be in the state of
>>> supporting legacy SPI? Can we convert all TI boards to driver model?
>>
>> We _really_ need some way to support more than one board per binary
>> before we can move everything to DM only.
>>
>> I think we can kind of do this today if we stick to using platform data
>> for everything that's board-specific rather than SoC-defined.  What we
>> talked about at ELCE was auto-generating the pdata from the device tree,
>> I think.
>
>We discussed this on IRC but since that doesn't exist as far as the
>mailing list is concerned...
>
>The current plan is:
>
>- Adjust build system to optionally build a u-boot.img in FIT format
>that includes the U-Boot binary and >1 device tree files
>- Adjust SPL to load this
>- Add a way for SPL to determine which device tree to select (by
>calling a board-specific function)
>- Have SPL pass this selected device tree to U-Boot when it starts

Can dtb be sperated from the final u-boot.img, if using SPL?
I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
And the dtb is shared with linux kernel.

Regards,
Peng.
>
>Thus we should be able to support more than one board with a single
>U-Boot image. Of course this is not a perfect solution (e.g. it is
>inefficient since the DTs are likely to be largely the same) but it
>should be a good first step.
>
>I'm going to try this out with sunxi initially and plan to get some
>patches out by the end of the week.
>
>Regards,
>Simon
>_______________________________________________
>U-Boot mailing list
>U-Boot at lists.denx.de
>http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Simon Glass]

Hi Peng,

On 25 January 2016 at 18:55, Peng Fan <van.freenix@gmail.com> wrote:
> Hi Simon,
>
> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>>+Hans
>>
>>Hi Tom,
>>
>>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>>> +Mugunthan, Tom
>>>>
>>>> On 17 January 2016 at 03:56, Christophe Ricard
>>>> <christophe.ricard@gmail.com> wrote:
>>>> > Convert omap3_spi driver to DM and keep compatibility with previous
>>>> > mode.
>>>> >
>>>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>>>> > ---
>>>> >
>>>> >  drivers/spi/Kconfig     |   6 +
>>>> >  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>>>> >  drivers/spi/omap3_spi.h |  14 +-
>>>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>>>>
>>>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>>>> would be possible to use a common pointer type and reduce this.
>>>>
>>>> But perhaps it does not matter - how long must we be in the state of
>>>> supporting legacy SPI? Can we convert all TI boards to driver model?
>>>
>>> We _really_ need some way to support more than one board per binary
>>> before we can move everything to DM only.
>>>
>>> I think we can kind of do this today if we stick to using platform data
>>> for everything that's board-specific rather than SoC-defined.  What we
>>> talked about at ELCE was auto-generating the pdata from the device tree,
>>> I think.
>>
>>We discussed this on IRC but since that doesn't exist as far as the
>>mailing list is concerned...
>>
>>The current plan is:
>>
>>- Adjust build system to optionally build a u-boot.img in FIT format
>>that includes the U-Boot binary and >1 device tree files
>>- Adjust SPL to load this
>>- Add a way for SPL to determine which device tree to select (by
>>calling a board-specific function)
>>- Have SPL pass this selected device tree to U-Boot when it starts
>
> Can dtb be sperated from the final u-boot.img, if using SPL?
> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> And the dtb is shared with linux kernel.

The way I have it is that u-boot.img include U-Boot and multiple .dtb
files. Then SPL selects the correct one and passes it to U-Boot.

It could be passed to the kernel also, but then you would need to
upgrade your firmware to upgrade your kernel. If that's what you want,
it would not be hard to implement. But I am not planning that for this
work - it seems like a separate feature to me.

>
> Regards,
> Peng.
>>
>>Thus we should be able to support more than one board with a single
>>U-Boot image. Of course this is not a perfect solution (e.g. it is
>>inefficient since the DTs are likely to be largely the same) but it
>>should be a good first step.
>>
>>I'm going to try this out with sunxi initially and plan to get some
>>patches out by the end of the week.
>>
>>Regards,
>>Simon

Regards
Simon

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Tom Rini]

On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote:
> Hi Simon,
> 
> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
> >+Hans
> >
> >Hi Tom,
> >
> >On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> >>> +Mugunthan, Tom
> >>>
> >>> On 17 January 2016 at 03:56, Christophe Ricard
> >>> <christophe.ricard@gmail.com> wrote:
> >>> > Convert omap3_spi driver to DM and keep compatibility with previous
> >>> > mode.
> >>> >
> >>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
> >>> > ---
> >>> >
> >>> >  drivers/spi/Kconfig     |   6 +
> >>> >  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
> >>> >  drivers/spi/omap3_spi.h |  14 +-
> >>> >  3 files changed, 402 insertions(+), 57 deletions(-)
> >>>
> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it
> >>> would be possible to use a common pointer type and reduce this.
> >>>
> >>> But perhaps it does not matter - how long must we be in the state of
> >>> supporting legacy SPI? Can we convert all TI boards to driver model?
> >>
> >> We _really_ need some way to support more than one board per binary
> >> before we can move everything to DM only.
> >>
> >> I think we can kind of do this today if we stick to using platform data
> >> for everything that's board-specific rather than SoC-defined.  What we
> >> talked about at ELCE was auto-generating the pdata from the device tree,
> >> I think.
> >
> >We discussed this on IRC but since that doesn't exist as far as the
> >mailing list is concerned...
> >
> >The current plan is:
> >
> >- Adjust build system to optionally build a u-boot.img in FIT format
> >that includes the U-Boot binary and >1 device tree files
> >- Adjust SPL to load this
> >- Add a way for SPL to determine which device tree to select (by
> >calling a board-specific function)
> >- Have SPL pass this selected device tree to U-Boot when it starts
> 
> Can dtb be sperated from the final u-boot.img, if using SPL?
> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> And the dtb is shared with linux kernel.

This sounds similar, but different.  The problem I'm asking to be solved
is that at the starting point, there are no DTBs on the hardware.  But
we can in software easily and reliable tell which of say 3 boards we are
on.  At that point, we need to make sure that both SPL and then U-Boot
know which board they are on.  And if in U-Boot we use the DT to pass in
all data, it has to be correct.  It sounds to me like you're describing
the case where the HW has the dtb stored at a known location and you
just don't need it embedded within SPL/U-Boot.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160125/740f7cc4/attachment.sig>

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Peng Fan]

On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote:
>On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote:
>> Hi Simon,
>> 
>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>> >+Hans
>> >
>> >Hi Tom,
>> >
>> >On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>> >>> +Mugunthan, Tom
>> >>>
>> >>> On 17 January 2016 at 03:56, Christophe Ricard
>> >>> <christophe.ricard@gmail.com> wrote:
>> >>> > Convert omap3_spi driver to DM and keep compatibility with previous
>> >>> > mode.
>> >>> >
>> >>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>> >>> > ---
>> >>> >
>> >>> >  drivers/spi/Kconfig     |   6 +
>> >>> >  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>> >>> >  drivers/spi/omap3_spi.h |  14 +-
>> >>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>> >>>
>> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>> >>> would be possible to use a common pointer type and reduce this.
>> >>>
>> >>> But perhaps it does not matter - how long must we be in the state of
>> >>> supporting legacy SPI? Can we convert all TI boards to driver model?
>> >>
>> >> We _really_ need some way to support more than one board per binary
>> >> before we can move everything to DM only.
>> >>
>> >> I think we can kind of do this today if we stick to using platform data
>> >> for everything that's board-specific rather than SoC-defined.  What we
>> >> talked about at ELCE was auto-generating the pdata from the device tree,
>> >> I think.
>> >
>> >We discussed this on IRC but since that doesn't exist as far as the
>> >mailing list is concerned...
>> >
>> >The current plan is:
>> >
>> >- Adjust build system to optionally build a u-boot.img in FIT format
>> >that includes the U-Boot binary and >1 device tree files
>> >- Adjust SPL to load this
>> >- Add a way for SPL to determine which device tree to select (by
>> >calling a board-specific function)
>> >- Have SPL pass this selected device tree to U-Boot when it starts
>> 
>> Can dtb be sperated from the final u-boot.img, if using SPL?
>> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>> And the dtb is shared with linux kernel.
>
>This sounds similar, but different.  The problem I'm asking to be solved
>is that at the starting point, there are no DTBs on the hardware.  But

Oh. Thanks for explanation.

>we can in software easily and reliable tell which of say 3 boards we are
>on.  At that point, we need to make sure that both SPL and then U-Boot
>know which board they are on.  And if in U-Boot we use the DT to pass in
>all data, it has to be correct.  It sounds to me like you're describing
>the case where the HW has the dtb stored at a known location and you
>just don't need it embedded within SPL/U-Boot.

Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file.

Thanks,
Peng.
>
>-- 
>Tom

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Tom Rini]

On Tue, Jan 26, 2016 at 10:58:47AM +0800, Peng Fan wrote:
> On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote:
> >On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote:
> >> Hi Simon,
> >> 
> >> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
> >> >+Hans
> >> >
> >> >Hi Tom,
> >> >
> >> >On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
> >> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> >> >>> +Mugunthan, Tom
> >> >>>
> >> >>> On 17 January 2016 at 03:56, Christophe Ricard
> >> >>> <christophe.ricard@gmail.com> wrote:
> >> >>> > Convert omap3_spi driver to DM and keep compatibility with previous
> >> >>> > mode.
> >> >>> >
> >> >>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
> >> >>> > ---
> >> >>> >
> >> >>> >  drivers/spi/Kconfig     |   6 +
> >> >>> >  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
> >> >>> >  drivers/spi/omap3_spi.h |  14 +-
> >> >>> >  3 files changed, 402 insertions(+), 57 deletions(-)
> >> >>>
> >> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it
> >> >>> would be possible to use a common pointer type and reduce this.
> >> >>>
> >> >>> But perhaps it does not matter - how long must we be in the state of
> >> >>> supporting legacy SPI? Can we convert all TI boards to driver model?
> >> >>
> >> >> We _really_ need some way to support more than one board per binary
> >> >> before we can move everything to DM only.
> >> >>
> >> >> I think we can kind of do this today if we stick to using platform data
> >> >> for everything that's board-specific rather than SoC-defined.  What we
> >> >> talked about at ELCE was auto-generating the pdata from the device tree,
> >> >> I think.
> >> >
> >> >We discussed this on IRC but since that doesn't exist as far as the
> >> >mailing list is concerned...
> >> >
> >> >The current plan is:
> >> >
> >> >- Adjust build system to optionally build a u-boot.img in FIT format
> >> >that includes the U-Boot binary and >1 device tree files
> >> >- Adjust SPL to load this
> >> >- Add a way for SPL to determine which device tree to select (by
> >> >calling a board-specific function)
> >> >- Have SPL pass this selected device tree to U-Boot when it starts
> >> 
> >> Can dtb be sperated from the final u-boot.img, if using SPL?
> >> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> >> And the dtb is shared with linux kernel.
> >
> >This sounds similar, but different.  The problem I'm asking to be solved
> >is that at the starting point, there are no DTBs on the hardware.  But
> 
> Oh. Thanks for explanation.
> 
> >we can in software easily and reliable tell which of say 3 boards we are
> >on.  At that point, we need to make sure that both SPL and then U-Boot
> >know which board they are on.  And if in U-Boot we use the DT to pass in
> >all data, it has to be correct.  It sounds to me like you're describing
> >the case where the HW has the dtb stored at a known location and you
> >just don't need it embedded within SPL/U-Boot.
> 
> Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file.

Can you explain how this would work, or the use case for it?  We can't
always assume we're reading u-boot.img off FAT for example.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160126/65c12375/attachment.sig>

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Peng Fan]

On Tue, Jan 26, 2016 at 10:12:10AM -0500, Tom Rini wrote:
>On Tue, Jan 26, 2016 at 10:58:47AM +0800, Peng Fan wrote:
>> On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote:
>> >On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote:
>> >> Hi Simon,
>> >> 
>> >> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>> >> >+Hans
>> >> >
>> >> >Hi Tom,
>> >> >
>> >> >On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>> >> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>> >> >>> +Mugunthan, Tom
>> >> >>>
>> >> >>> On 17 January 2016 at 03:56, Christophe Ricard
>> >> >>> <christophe.ricard@gmail.com> wrote:
>> >> >>> > Convert omap3_spi driver to DM and keep compatibility with previous
>> >> >>> > mode.
>> >> >>> >
>> >> >>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>> >> >>> > ---
>> >> >>> >
>> >> >>> >  drivers/spi/Kconfig     |   6 +
>> >> >>> >  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>> >> >>> >  drivers/spi/omap3_spi.h |  14 +-
>> >> >>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>> >> >>>
>> >> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>> >> >>> would be possible to use a common pointer type and reduce this.
>> >> >>>
>> >> >>> But perhaps it does not matter - how long must we be in the state of
>> >> >>> supporting legacy SPI? Can we convert all TI boards to driver model?
>> >> >>
>> >> >> We _really_ need some way to support more than one board per binary
>> >> >> before we can move everything to DM only.
>> >> >>
>> >> >> I think we can kind of do this today if we stick to using platform data
>> >> >> for everything that's board-specific rather than SoC-defined.  What we
>> >> >> talked about at ELCE was auto-generating the pdata from the device tree,
>> >> >> I think.
>> >> >
>> >> >We discussed this on IRC but since that doesn't exist as far as the
>> >> >mailing list is concerned...
>> >> >
>> >> >The current plan is:
>> >> >
>> >> >- Adjust build system to optionally build a u-boot.img in FIT format
>> >> >that includes the U-Boot binary and >1 device tree files
>> >> >- Adjust SPL to load this
>> >> >- Add a way for SPL to determine which device tree to select (by
>> >> >calling a board-specific function)
>> >> >- Have SPL pass this selected device tree to U-Boot when it starts
>> >> 
>> >> Can dtb be sperated from the final u-boot.img, if using SPL?
>> >> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>> >> And the dtb is shared with linux kernel.
>> >
>> >This sounds similar, but different.  The problem I'm asking to be solved
>> >is that at the starting point, there are no DTBs on the hardware.  But
>> 
>> Oh. Thanks for explanation.
>> 
>> >we can in software easily and reliable tell which of say 3 boards we are
>> >on.  At that point, we need to make sure that both SPL and then U-Boot
>> >know which board they are on.  And if in U-Boot we use the DT to pass in
>> >all data, it has to be correct.  It sounds to me like you're describing
>> >the case where the HW has the dtb stored at a known location and you
>> >just don't need it embedded within SPL/U-Boot.
>> 
>> Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file.
>
>Can you explain how this would work, or the use case for it?  We can't
>always assume we're reading u-boot.img off FAT for example.

I have no idea on this for now (:.

Regards,
Peng.

>
>-- 
>Tom

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Christophe Ricard]

Hi Simon, Tom,

I assume the approach you are taking is also valuable for the i2c: 
omap24xx patch serie:
http://lists.denx.de/pipermail/u-boot/2016-January/241676.html

What are your recommendation about the pending patches ?
Should i send back only the one not taking care of the DM conversion and 
send another serie later ?

I have seen some work ongoing on this topic on the u-boot-fdt tree on 
the spl-working branch.
Is there a more accurate place to follow this work ?

Best Regards
Christophe

On 26/01/2016 02:55, Peng Fan wrote:
> Hi Simon,
>
> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>> +Hans
>>
>> Hi Tom,
>>
>> On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>>> +Mugunthan, Tom
>>>>
>>>> On 17 January 2016 at 03:56, Christophe Ricard
>>>> <christophe.ricard@gmail.com> wrote:
>>>>> Convert omap3_spi driver to DM and keep compatibility with previous
>>>>> mode.
>>>>>
>>>>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>>>>> ---
>>>>>
>>>>>   drivers/spi/Kconfig     |   6 +
>>>>>   drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>>>>>   drivers/spi/omap3_spi.h |  14 +-
>>>>>   3 files changed, 402 insertions(+), 57 deletions(-)
>>>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>>>> would be possible to use a common pointer type and reduce this.
>>>>
>>>> But perhaps it does not matter - how long must we be in the state of
>>>> supporting legacy SPI? Can we convert all TI boards to driver model?
>>> We _really_ need some way to support more than one board per binary
>>> before we can move everything to DM only.
>>>
>>> I think we can kind of do this today if we stick to using platform data
>>> for everything that's board-specific rather than SoC-defined.  What we
>>> talked about at ELCE was auto-generating the pdata from the device tree,
>>> I think.
>> We discussed this on IRC but since that doesn't exist as far as the
>> mailing list is concerned...
>>
>> The current plan is:
>>
>> - Adjust build system to optionally build a u-boot.img in FIT format
>> that includes the U-Boot binary and >1 device tree files
>> - Adjust SPL to load this
>> - Add a way for SPL to determine which device tree to select (by
>> calling a board-specific function)
>> - Have SPL pass this selected device tree to U-Boot when it starts
> Can dtb be sperated from the final u-boot.img, if using SPL?
> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> And the dtb is shared with linux kernel.
>
> Regards,
> Peng.
>> Thus we should be able to support more than one board with a single
>> U-Boot image. Of course this is not a perfect solution (e.g. it is
>> inefficient since the DTs are likely to be largely the same) but it
>> should be a good first step.
>>
>> I'm going to try this out with sunxi initially and plan to get some
>> patches out by the end of the week.
>>
>> Regards,
>> Simon
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Tom Rini]

On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
> Hi Simon, Tom,
> 
> I assume the approach you are taking is also valuable for the i2c:
> omap24xx patch serie:
> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
> 
> What are your recommendation about the pending patches ?
> Should i send back only the one not taking care of the DM conversion
> and send another serie later ?
> 
> I have seen some work ongoing on this topic on the u-boot-fdt tree
> on the spl-working branch.
> Is there a more accurate place to follow this work ?

For i2c, aside from needing to defer removing the non-DM code for a
while yet, there were some review comments to address in a v2 or answer
as intentional.  For SPI, it's all looking good and I'm assuming Jagan
will have a SPI PR soon.  Thanks!

> 
> Best Regards
> Christophe
> 
> On 26/01/2016 02:55, Peng Fan wrote:
> >Hi Simon,
> >
> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
> >>+Hans
> >>
> >>Hi Tom,
> >>
> >>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> >>>>+Mugunthan, Tom
> >>>>
> >>>>On 17 January 2016 at 03:56, Christophe Ricard
> >>>><christophe.ricard@gmail.com> wrote:
> >>>>>Convert omap3_spi driver to DM and keep compatibility with previous
> >>>>>mode.
> >>>>>
> >>>>>Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
> >>>>>---
> >>>>>
> >>>>>  drivers/spi/Kconfig     |   6 +
> >>>>>  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
> >>>>>  drivers/spi/omap3_spi.h |  14 +-
> >>>>>  3 files changed, 402 insertions(+), 57 deletions(-)
> >>>>This is a pretty painful conversion, with lots of #ifdefs. I think it
> >>>>would be possible to use a common pointer type and reduce this.
> >>>>
> >>>>But perhaps it does not matter - how long must we be in the state of
> >>>>supporting legacy SPI? Can we convert all TI boards to driver model?
> >>>We _really_ need some way to support more than one board per binary
> >>>before we can move everything to DM only.
> >>>
> >>>I think we can kind of do this today if we stick to using platform data
> >>>for everything that's board-specific rather than SoC-defined.  What we
> >>>talked about at ELCE was auto-generating the pdata from the device tree,
> >>>I think.
> >>We discussed this on IRC but since that doesn't exist as far as the
> >>mailing list is concerned...
> >>
> >>The current plan is:
> >>
> >>- Adjust build system to optionally build a u-boot.img in FIT format
> >>that includes the U-Boot binary and >1 device tree files
> >>- Adjust SPL to load this
> >>- Add a way for SPL to determine which device tree to select (by
> >>calling a board-specific function)
> >>- Have SPL pass this selected device tree to U-Boot when it starts
> >Can dtb be sperated from the final u-boot.img, if using SPL?
> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> >And the dtb is shared with linux kernel.
> >
> >Regards,
> >Peng.
> >>Thus we should be able to support more than one board with a single
> >>U-Boot image. Of course this is not a perfect solution (e.g. it is
> >>inefficient since the DTs are likely to be largely the same) but it
> >>should be a good first step.
> >>
> >>I'm going to try this out with sunxi initially and plan to get some
> >>patches out by the end of the week.
> >>
> >>Regards,
> >>Simon
> >>_______________________________________________
> >>U-Boot mailing list
> >>U-Boot at lists.denx.de
> >>http://lists.denx.de/mailman/listinfo/u-boot
> 

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160208/ada06fe0/attachment.sig>

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Jagan Teki]

On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote:
> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>> Hi Simon, Tom,
>>
>> I assume the approach you are taking is also valuable for the i2c:
>> omap24xx patch serie:
>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>>
>> What are your recommendation about the pending patches ?
>> Should i send back only the one not taking care of the DM conversion
>> and send another serie later ?
>>
>> I have seen some work ongoing on this topic on the u-boot-fdt tree
>> on the spl-working branch.
>> Is there a more accurate place to follow this work ?
>
> For i2c, aside from needing to defer removing the non-DM code for a
> while yet, there were some review comments to address in a v2 or answer
> as intentional.  For SPI, it's all looking good and I'm assuming Jagan
> will have a SPI PR soon.  Thanks!

Yes, by this week-end.

>>
>> On 26/01/2016 02:55, Peng Fan wrote:
>> >Hi Simon,
>> >
>> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>> >>+Hans
>> >>
>> >>Hi Tom,
>> >>
>> >>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>> >>>>+Mugunthan, Tom
>> >>>>
>> >>>>On 17 January 2016 at 03:56, Christophe Ricard
>> >>>><christophe.ricard@gmail.com> wrote:
>> >>>>>Convert omap3_spi driver to DM and keep compatibility with previous
>> >>>>>mode.
>> >>>>>
>> >>>>>Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>> >>>>>---
>> >>>>>
>> >>>>>  drivers/spi/Kconfig     |   6 +
>> >>>>>  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>> >>>>>  drivers/spi/omap3_spi.h |  14 +-
>> >>>>>  3 files changed, 402 insertions(+), 57 deletions(-)
>> >>>>This is a pretty painful conversion, with lots of #ifdefs. I think it
>> >>>>would be possible to use a common pointer type and reduce this.
>> >>>>
>> >>>>But perhaps it does not matter - how long must we be in the state of
>> >>>>supporting legacy SPI? Can we convert all TI boards to driver model?
>> >>>We _really_ need some way to support more than one board per binary
>> >>>before we can move everything to DM only.
>> >>>
>> >>>I think we can kind of do this today if we stick to using platform data
>> >>>for everything that's board-specific rather than SoC-defined.  What we
>> >>>talked about at ELCE was auto-generating the pdata from the device tree,
>> >>>I think.
>> >>We discussed this on IRC but since that doesn't exist as far as the
>> >>mailing list is concerned...
>> >>
>> >>The current plan is:
>> >>
>> >>- Adjust build system to optionally build a u-boot.img in FIT format
>> >>that includes the U-Boot binary and >1 device tree files
>> >>- Adjust SPL to load this
>> >>- Add a way for SPL to determine which device tree to select (by
>> >>calling a board-specific function)
>> >>- Have SPL pass this selected device tree to U-Boot when it starts
>> >Can dtb be sperated from the final u-boot.img, if using SPL?
>> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>> >And the dtb is shared with linux kernel.
>> >
>> >Regards,
>> >Peng.
>> >>Thus we should be able to support more than one board with a single
>> >>U-Boot image. Of course this is not a perfect solution (e.g. it is
>> >>inefficient since the DTs are likely to be largely the same) but it
>> >>should be a good first step.
>> >>
>> >>I'm going to try this out with sunxi initially and plan to get some
>> >>patches out by the end of the week.

-- 
Jagan.

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Jagan Teki]

On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote:
> On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote:
>> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>>> Hi Simon, Tom,
>>>
>>> I assume the approach you are taking is also valuable for the i2c:
>>> omap24xx patch serie:
>>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>>>
>>> What are your recommendation about the pending patches ?
>>> Should i send back only the one not taking care of the DM conversion
>>> and send another serie later ?
>>>
>>> I have seen some work ongoing on this topic on the u-boot-fdt tree
>>> on the spl-working branch.
>>> Is there a more accurate place to follow this work ?
>>
>> For i2c, aside from needing to defer removing the non-DM code for a
>> while yet, there were some review comments to address in a v2 or answer
>> as intentional.  For SPI, it's all looking good and I'm assuming Jagan
>> will have a SPI PR soon.  Thanks!
>
> Yes, by this week-end.

Any idea 4/4 got differed in patchwork [1], do we have next version
patches for these?

[1] https://patchwork.ozlabs.org/patch/569241/

>
>>>
>>> On 26/01/2016 02:55, Peng Fan wrote:
>>> >Hi Simon,
>>> >
>>> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>>> >>+Hans
>>> >>
>>> >>Hi Tom,
>>> >>
>>> >>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>>> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>> >>>>+Mugunthan, Tom
>>> >>>>
>>> >>>>On 17 January 2016 at 03:56, Christophe Ricard
>>> >>>><christophe.ricard@gmail.com> wrote:
>>> >>>>>Convert omap3_spi driver to DM and keep compatibility with previous
>>> >>>>>mode.
>>> >>>>>
>>> >>>>>Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>>> >>>>>---
>>> >>>>>
>>> >>>>>  drivers/spi/Kconfig     |   6 +
>>> >>>>>  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>>> >>>>>  drivers/spi/omap3_spi.h |  14 +-
>>> >>>>>  3 files changed, 402 insertions(+), 57 deletions(-)
>>> >>>>This is a pretty painful conversion, with lots of #ifdefs. I think it
>>> >>>>would be possible to use a common pointer type and reduce this.
>>> >>>>
>>> >>>>But perhaps it does not matter - how long must we be in the state of
>>> >>>>supporting legacy SPI? Can we convert all TI boards to driver model?
>>> >>>We _really_ need some way to support more than one board per binary
>>> >>>before we can move everything to DM only.
>>> >>>
>>> >>>I think we can kind of do this today if we stick to using platform data
>>> >>>for everything that's board-specific rather than SoC-defined.  What we
>>> >>>talked about at ELCE was auto-generating the pdata from the device tree,
>>> >>>I think.
>>> >>We discussed this on IRC but since that doesn't exist as far as the
>>> >>mailing list is concerned...
>>> >>
>>> >>The current plan is:
>>> >>
>>> >>- Adjust build system to optionally build a u-boot.img in FIT format
>>> >>that includes the U-Boot binary and >1 device tree files
>>> >>- Adjust SPL to load this
>>> >>- Add a way for SPL to determine which device tree to select (by
>>> >>calling a board-specific function)
>>> >>- Have SPL pass this selected device tree to U-Boot when it starts
>>> >Can dtb be sperated from the final u-boot.img, if using SPL?
>>> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>>> >And the dtb is shared with linux kernel.
>>> >
>>> >Regards,
>>> >Peng.
>>> >>Thus we should be able to support more than one board with a single
>>> >>U-Boot image. Of course this is not a perfect solution (e.g. it is
>>> >>inefficient since the DTs are likely to be largely the same) but it
>>> >>should be a good first step.
>>> >>
>>> >>I'm going to try this out with sunxi initially and plan to get some
>>> >>patches out by the end of the week.

-- 
Jagan.

[U-Boot] [PATCH 1/4] spi: omap3: Remove unused variable irqstatus in omap3_spi_txrx

[Jagan Teki]

On 21 January 2016 at 08:16, Simon Glass <sjg@chromium.org> wrote:
> On 17 January 2016 at 03:56, Christophe Ricard
> <christophe.ricard@gmail.com> wrote:
>> Remove unused variable irqstatus in omap3_spi_txrx
>>
>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>> ---
>>
>>  drivers/spi/omap3_spi.c | 2 --
>>  1 file changed, 2 deletions(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Reviewed-by: Jagan Teki <jteki@openedev.com>

-- 
Jagan.

[U-Boot] [PATCH 2/4] spi: spi-uclass: Set slave wordlen with SPI_DEFAULT_WORDLEN

[Jagan Teki]

On 21 January 2016 at 08:16, Simon Glass <sjg@chromium.org> wrote:
> On 17 January 2016 at 03:56, Christophe Ricard
> <christophe.ricard@gmail.com> wrote:
>> In some case wordlen may not be set. Use SPI_DEFAULT_WORDLEN as default.
>>
>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>> ---
>>
>>  drivers/spi/spi-uclass.c | 1 +
>>  1 file changed, 1 insertion(+)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Reviewed-by: Jagan Teki <jteki@openedev.com>

-- 
Jagan.

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Christophe Ricard]

Hi Jagan,

My understanding is that some work are ongoing around spl in order to 
support correctly DM for all spi/i2c bus drivers.
As a consequence patch 4 got differed.

Hopefully Simon or Tom can comment.

Are you ok in applying patch 1 and 2 only ? or should i send a new serie 
with only patch 1 and 2 ?

Best Regards
Christophe

On 10/02/2016 20:16, Jagan Teki wrote:
> On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote:
>> On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote:
>>> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>>>> Hi Simon, Tom,
>>>>
>>>> I assume the approach you are taking is also valuable for the i2c:
>>>> omap24xx patch serie:
>>>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>>>>
>>>> What are your recommendation about the pending patches ?
>>>> Should i send back only the one not taking care of the DM conversion
>>>> and send another serie later ?
>>>>
>>>> I have seen some work ongoing on this topic on the u-boot-fdt tree
>>>> on the spl-working branch.
>>>> Is there a more accurate place to follow this work ?
>>> For i2c, aside from needing to defer removing the non-DM code for a
>>> while yet, there were some review comments to address in a v2 or answer
>>> as intentional.  For SPI, it's all looking good and I'm assuming Jagan
>>> will have a SPI PR soon.  Thanks!
>> Yes, by this week-end.
> Any idea 4/4 got differed in patchwork [1], do we have next version
> patches for these?
>
> [1] https://patchwork.ozlabs.org/patch/569241/
>
>>>> On 26/01/2016 02:55, Peng Fan wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>>>>>> +Hans
>>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>>>>>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>>>>>>> +Mugunthan, Tom
>>>>>>>>
>>>>>>>> On 17 January 2016 at 03:56, Christophe Ricard
>>>>>>>> <christophe.ricard@gmail.com> wrote:
>>>>>>>>> Convert omap3_spi driver to DM and keep compatibility with previous
>>>>>>>>> mode.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>>   drivers/spi/Kconfig     |   6 +
>>>>>>>>>   drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
>>>>>>>>>   drivers/spi/omap3_spi.h |  14 +-
>>>>>>>>>   3 files changed, 402 insertions(+), 57 deletions(-)
>>>>>>>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>>>>>>>> would be possible to use a common pointer type and reduce this.
>>>>>>>>
>>>>>>>> But perhaps it does not matter - how long must we be in the state of
>>>>>>>> supporting legacy SPI? Can we convert all TI boards to driver model?
>>>>>>> We _really_ need some way to support more than one board per binary
>>>>>>> before we can move everything to DM only.
>>>>>>>
>>>>>>> I think we can kind of do this today if we stick to using platform data
>>>>>>> for everything that's board-specific rather than SoC-defined.  What we
>>>>>>> talked about at ELCE was auto-generating the pdata from the device tree,
>>>>>>> I think.
>>>>>> We discussed this on IRC but since that doesn't exist as far as the
>>>>>> mailing list is concerned...
>>>>>>
>>>>>> The current plan is:
>>>>>>
>>>>>> - Adjust build system to optionally build a u-boot.img in FIT format
>>>>>> that includes the U-Boot binary and >1 device tree files
>>>>>> - Adjust SPL to load this
>>>>>> - Add a way for SPL to determine which device tree to select (by
>>>>>> calling a board-specific function)
>>>>>> - Have SPL pass this selected device tree to U-Boot when it starts
>>>>> Can dtb be sperated from the final u-boot.img, if using SPL?
>>>>> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>>>>> And the dtb is shared with linux kernel.
>>>>>
>>>>> Regards,
>>>>> Peng.
>>>>>> Thus we should be able to support more than one board with a single
>>>>>> U-Boot image. Of course this is not a perfect solution (e.g. it is
>>>>>> inefficient since the DTs are likely to be largely the same) but it
>>>>>> should be a good first step.
>>>>>>
>>>>>> I'm going to try this out with sunxi initially and plan to get some
>>>>>> patches out by the end of the week.

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Tom Rini]

On Wed, Feb 10, 2016 at 10:00:55PM +0100, Christophe Ricard wrote:

> Hi Jagan,
> 
> My understanding is that some work are ongoing around spl in order
> to support correctly DM for all spi/i2c bus drivers.
> As a consequence patch 4 got differed.
>
> Hopefully Simon or Tom can comment.

Yes, I deferred 4/4 because until we convert all of the platforms to DM
(and Simon is making progress on what's required there).

> Are you ok in applying patch 1 and 2 only ? or should i send a new
> serie with only patch 1 and 2 ?

1, 2 and 3? should be fine to go now and you shouldn't need to re-send
them.

> 
> Best Regards
> Christophe
> 
> On 10/02/2016 20:16, Jagan Teki wrote:
> >On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote:
> >>On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote:
> >>>On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
> >>>>Hi Simon, Tom,
> >>>>
> >>>>I assume the approach you are taking is also valuable for the i2c:
> >>>>omap24xx patch serie:
> >>>>http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
> >>>>
> >>>>What are your recommendation about the pending patches ?
> >>>>Should i send back only the one not taking care of the DM conversion
> >>>>and send another serie later ?
> >>>>
> >>>>I have seen some work ongoing on this topic on the u-boot-fdt tree
> >>>>on the spl-working branch.
> >>>>Is there a more accurate place to follow this work ?
> >>>For i2c, aside from needing to defer removing the non-DM code for a
> >>>while yet, there were some review comments to address in a v2 or answer
> >>>as intentional.  For SPI, it's all looking good and I'm assuming Jagan
> >>>will have a SPI PR soon.  Thanks!
> >>Yes, by this week-end.
> >Any idea 4/4 got differed in patchwork [1], do we have next version
> >patches for these?
> >
> >[1] https://patchwork.ozlabs.org/patch/569241/
> >
> >>>>On 26/01/2016 02:55, Peng Fan wrote:
> >>>>>Hi Simon,
> >>>>>
> >>>>>On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
> >>>>>>+Hans
> >>>>>>
> >>>>>>Hi Tom,
> >>>>>>
> >>>>>>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
> >>>>>>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> >>>>>>>>+Mugunthan, Tom
> >>>>>>>>
> >>>>>>>>On 17 January 2016 at 03:56, Christophe Ricard
> >>>>>>>><christophe.ricard@gmail.com> wrote:
> >>>>>>>>>Convert omap3_spi driver to DM and keep compatibility with previous
> >>>>>>>>>mode.
> >>>>>>>>>
> >>>>>>>>>Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
> >>>>>>>>>---
> >>>>>>>>>
> >>>>>>>>>  drivers/spi/Kconfig     |   6 +
> >>>>>>>>>  drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------
> >>>>>>>>>  drivers/spi/omap3_spi.h |  14 +-
> >>>>>>>>>  3 files changed, 402 insertions(+), 57 deletions(-)
> >>>>>>>>This is a pretty painful conversion, with lots of #ifdefs. I think it
> >>>>>>>>would be possible to use a common pointer type and reduce this.
> >>>>>>>>
> >>>>>>>>But perhaps it does not matter - how long must we be in the state of
> >>>>>>>>supporting legacy SPI? Can we convert all TI boards to driver model?
> >>>>>>>We _really_ need some way to support more than one board per binary
> >>>>>>>before we can move everything to DM only.
> >>>>>>>
> >>>>>>>I think we can kind of do this today if we stick to using platform data
> >>>>>>>for everything that's board-specific rather than SoC-defined.  What we
> >>>>>>>talked about at ELCE was auto-generating the pdata from the device tree,
> >>>>>>>I think.
> >>>>>>We discussed this on IRC but since that doesn't exist as far as the
> >>>>>>mailing list is concerned...
> >>>>>>
> >>>>>>The current plan is:
> >>>>>>
> >>>>>>- Adjust build system to optionally build a u-boot.img in FIT format
> >>>>>>that includes the U-Boot binary and >1 device tree files
> >>>>>>- Adjust SPL to load this
> >>>>>>- Add a way for SPL to determine which device tree to select (by
> >>>>>>calling a board-specific function)
> >>>>>>- Have SPL pass this selected device tree to U-Boot when it starts
> >>>>>Can dtb be sperated from the final u-boot.img, if using SPL?
> >>>>>I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> >>>>>And the dtb is shared with linux kernel.
> >>>>>
> >>>>>Regards,
> >>>>>Peng.
> >>>>>>Thus we should be able to support more than one board with a single
> >>>>>>U-Boot image. Of course this is not a perfect solution (e.g. it is
> >>>>>>inefficient since the DTs are likely to be largely the same) but it
> >>>>>>should be a good first step.
> >>>>>>
> >>>>>>I'm going to try this out with sunxi initially and plan to get some
> >>>>>>patches out by the end of the week.
> 

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160210/1b7ad36a/attachment-0001.sig>

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Jagan Teki]

On 11 February 2016 at 02:30, Christophe Ricard
<christophe.ricard@gmail.com> wrote:
> Hi Jagan,
>
> My understanding is that some work are ongoing around spl in order to
> support correctly DM for all spi/i2c bus drivers.
> As a consequence patch 4 got differed.
>
> Hopefully Simon or Tom can comment.
>
> Are you ok in applying patch 1 and 2 only ? or should i send a new serie
> with only patch 1 and 2 ?

3/4 looks not good to me with so many ifdef, may we can do something
clear similar to kirkwood_spi does.

>
> On 10/02/2016 20:16, Jagan Teki wrote:
>>
>> On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote:
>>>
>>> On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote:
>>>>
>>>> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>>>>>
>>>>> Hi Simon, Tom,
>>>>>
>>>>> I assume the approach you are taking is also valuable for the i2c:
>>>>> omap24xx patch serie:
>>>>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>>>>>
>>>>> What are your recommendation about the pending patches ?
>>>>> Should i send back only the one not taking care of the DM conversion
>>>>> and send another serie later ?
>>>>>
>>>>> I have seen some work ongoing on this topic on the u-boot-fdt tree
>>>>> on the spl-working branch.
>>>>> Is there a more accurate place to follow this work ?
>>>>
>>>> For i2c, aside from needing to defer removing the non-DM code for a
>>>> while yet, there were some review comments to address in a v2 or answer
>>>> as intentional.  For SPI, it's all looking good and I'm assuming Jagan
>>>> will have a SPI PR soon.  Thanks!
>>>
>>> Yes, by this week-end.
>>
>> Any idea 4/4 got differed in patchwork [1], do we have next version
>> patches for these?
>>
>> [1] https://patchwork.ozlabs.org/patch/569241/
>>
>>>>> On 26/01/2016 02:55, Peng Fan wrote:
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>>>>>>>
>>>>>>> +Hans
>>>>>>>
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>>>>>>>>
>>>>>>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>>>>>>>>
>>>>>>>>> +Mugunthan, Tom
>>>>>>>>>
>>>>>>>>> On 17 January 2016 at 03:56, Christophe Ricard
>>>>>>>>> <christophe.ricard@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Convert omap3_spi driver to DM and keep compatibility with
>>>>>>>>>> previous
>>>>>>>>>> mode.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>>   drivers/spi/Kconfig     |   6 +
>>>>>>>>>>   drivers/spi/omap3_spi.c | 439
>>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++------
>>>>>>>>>>   drivers/spi/omap3_spi.h |  14 +-
>>>>>>>>>>   3 files changed, 402 insertions(+), 57 deletions(-)
>>>>>>>>>
>>>>>>>>> This is a pretty painful conversion, with lots of #ifdefs. I think
>>>>>>>>> it
>>>>>>>>> would be possible to use a common pointer type and reduce this.
>>>>>>>>>
>>>>>>>>> But perhaps it does not matter - how long must we be in the state
>>>>>>>>> of
>>>>>>>>> supporting legacy SPI? Can we convert all TI boards to driver
>>>>>>>>> model?
>>>>>>>>
>>>>>>>> We _really_ need some way to support more than one board per binary
>>>>>>>> before we can move everything to DM only.
>>>>>>>>
>>>>>>>> I think we can kind of do this today if we stick to using platform
>>>>>>>> data
>>>>>>>> for everything that's board-specific rather than SoC-defined.  What
>>>>>>>> we
>>>>>>>> talked about at ELCE was auto-generating the pdata from the device
>>>>>>>> tree,
>>>>>>>> I think.
>>>>>>>
>>>>>>> We discussed this on IRC but since that doesn't exist as far as the
>>>>>>> mailing list is concerned...
>>>>>>>
>>>>>>> The current plan is:
>>>>>>>
>>>>>>> - Adjust build system to optionally build a u-boot.img in FIT format
>>>>>>> that includes the U-Boot binary and >1 device tree files
>>>>>>> - Adjust SPL to load this
>>>>>>> - Add a way for SPL to determine which device tree to select (by
>>>>>>> calling a board-specific function)
>>>>>>> - Have SPL pass this selected device tree to U-Boot when it starts
>>>>>>
>>>>>> Can dtb be sperated from the final u-boot.img, if using SPL?
>>>>>> I mean let SPL load the u-boot.img and the dtb to correct DRAM
>>>>>> address.
>>>>>> And the dtb is shared with linux kernel.
>>>>>>
>>>>>> Regards,
>>>>>> Peng.
>>>>>>>
>>>>>>> Thus we should be able to support more than one board with a single
>>>>>>> U-Boot image. Of course this is not a perfect solution (e.g. it is
>>>>>>> inefficient since the DTs are likely to be largely the same) but it
>>>>>>> should be a good first step.
>>>>>>>
>>>>>>> I'm going to try this out with sunxi initially and plan to get some
>>>>>>> patches out by the end of the week.
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Jagan.

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Jagan Teki]

On 11 February 2016 at 20:31, Jagan Teki <jteki@openedev.com> wrote:
> On 11 February 2016 at 02:30, Christophe Ricard
> <christophe.ricard@gmail.com> wrote:
>> Hi Jagan,
>>
>> My understanding is that some work are ongoing around spl in order to
>> support correctly DM for all spi/i2c bus drivers.
>> As a consequence patch 4 got differed.
>>
>> Hopefully Simon or Tom can comment.
>>
>> Are you ok in applying patch 1 and 2 only ? or should i send a new serie
>> with only patch 1 and 2 ?
>
> 3/4 looks not good to me with so many ifdef, may we can do something
> clear similar to kirkwood_spi does.

I did some dm conversion on these long back which looks similar like
kirkwood_spi, will post them as well so-that we can discuss.

>
>>
>> On 10/02/2016 20:16, Jagan Teki wrote:
>>>
>>> On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote:
>>>>
>>>> On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote:
>>>>>
>>>>> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>>>>>>
>>>>>> Hi Simon, Tom,
>>>>>>
>>>>>> I assume the approach you are taking is also valuable for the i2c:
>>>>>> omap24xx patch serie:
>>>>>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>>>>>>
>>>>>> What are your recommendation about the pending patches ?
>>>>>> Should i send back only the one not taking care of the DM conversion
>>>>>> and send another serie later ?
>>>>>>
>>>>>> I have seen some work ongoing on this topic on the u-boot-fdt tree
>>>>>> on the spl-working branch.
>>>>>> Is there a more accurate place to follow this work ?
>>>>>
>>>>> For i2c, aside from needing to defer removing the non-DM code for a
>>>>> while yet, there were some review comments to address in a v2 or answer
>>>>> as intentional.  For SPI, it's all looking good and I'm assuming Jagan
>>>>> will have a SPI PR soon.  Thanks!
>>>>
>>>> Yes, by this week-end.
>>>
>>> Any idea 4/4 got differed in patchwork [1], do we have next version
>>> patches for these?
>>>
>>> [1] https://patchwork.ozlabs.org/patch/569241/
>>>
>>>>>> On 26/01/2016 02:55, Peng Fan wrote:
>>>>>>>
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>>>>>>>>
>>>>>>>> +Hans
>>>>>>>>
>>>>>>>> Hi Tom,
>>>>>>>>
>>>>>>>> On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>>>>>>>>>
>>>>>>>>>> +Mugunthan, Tom
>>>>>>>>>>
>>>>>>>>>> On 17 January 2016 at 03:56, Christophe Ricard
>>>>>>>>>> <christophe.ricard@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Convert omap3_spi driver to DM and keep compatibility with
>>>>>>>>>>> previous
>>>>>>>>>>> mode.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>   drivers/spi/Kconfig     |   6 +
>>>>>>>>>>>   drivers/spi/omap3_spi.c | 439
>>>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++------
>>>>>>>>>>>   drivers/spi/omap3_spi.h |  14 +-
>>>>>>>>>>>   3 files changed, 402 insertions(+), 57 deletions(-)
>>>>>>>>>>
>>>>>>>>>> This is a pretty painful conversion, with lots of #ifdefs. I think
>>>>>>>>>> it
>>>>>>>>>> would be possible to use a common pointer type and reduce this.
>>>>>>>>>>
>>>>>>>>>> But perhaps it does not matter - how long must we be in the state
>>>>>>>>>> of
>>>>>>>>>> supporting legacy SPI? Can we convert all TI boards to driver
>>>>>>>>>> model?
>>>>>>>>>
>>>>>>>>> We _really_ need some way to support more than one board per binary
>>>>>>>>> before we can move everything to DM only.
>>>>>>>>>
>>>>>>>>> I think we can kind of do this today if we stick to using platform
>>>>>>>>> data
>>>>>>>>> for everything that's board-specific rather than SoC-defined.  What
>>>>>>>>> we
>>>>>>>>> talked about at ELCE was auto-generating the pdata from the device
>>>>>>>>> tree,
>>>>>>>>> I think.
>>>>>>>>
>>>>>>>> We discussed this on IRC but since that doesn't exist as far as the
>>>>>>>> mailing list is concerned...
>>>>>>>>
>>>>>>>> The current plan is:
>>>>>>>>
>>>>>>>> - Adjust build system to optionally build a u-boot.img in FIT format
>>>>>>>> that includes the U-Boot binary and >1 device tree files
>>>>>>>> - Adjust SPL to load this
>>>>>>>> - Add a way for SPL to determine which device tree to select (by
>>>>>>>> calling a board-specific function)
>>>>>>>> - Have SPL pass this selected device tree to U-Boot when it starts
>>>>>>>
>>>>>>> Can dtb be sperated from the final u-boot.img, if using SPL?
>>>>>>> I mean let SPL load the u-boot.img and the dtb to correct DRAM
>>>>>>> address.
>>>>>>> And the dtb is shared with linux kernel.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Peng.
>>>>>>>>
>>>>>>>> Thus we should be able to support more than one board with a single
>>>>>>>> U-Boot image. Of course this is not a perfect solution (e.g. it is
>>>>>>>> inefficient since the DTs are likely to be largely the same) but it
>>>>>>>> should be a good first step.
>>>>>>>>
>>>>>>>> I'm going to try this out with sunxi initially and plan to get some
>>>>>>>> patches out by the end of the week.
>>
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
> --
> Jagan.



-- 
Jagan.