spi: DM_SPI migration timeout, remainder(2)

davinci_spi now support dt along with platform data, respective boards need to switch into dm for the same.

Cc Adam Ford <[email protected]>

Cc Vitaly Andrianov <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Peter Howard <[email protected]>

Cc Tom Rini <[email protected]>

Signed-off-by Jagan Teki <[email protected]>

---
 Makefile                  |   9 +++
 drivers/spi/Makefile      |   2 +-
 drivers/spi/davinci_spi.c | 157 --------------------------------------
 drivers/spi/spi.c         |  38 +++++++++
 4 files changed, 48 insertions(+), 158 deletions(-)

Makefile +9 -0

index 552687db53..d06cb5c287 100644
@@ -917,6 +917,15 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y)
        @echo "(possibly in a subsequent patch in your series)"
        @echo "before sending patches to the mailing list."
        @echo "===================================================="
+endif
+ifeq ($(CONFIG_DM_SPI),)
+ifeq ($(CONFIG_DAVINCI_SPI),y)
+       @echo "===================== WARNING ======================"
+       @echo "This board uses SPI driver from drivers/spi/ without"
+       @echo "enabling CONFIG_DM_SPI. Please enable CONFIG_DM_SPI"
+       @echo "otherwise SPI on this board, cannot work."
+       @echo "===================================================="
+endif
 endif
        @# Check that this build does not use CONFIG options that we do not
        @# know about unless they are in Kconfig. All the existing CONFIG

drivers/spi/Makefile +1 -1

index 7242ea7e40..cf5a5cccc0 100644
@@ -6,6 +6,7 @@
 # There are many options which enable SPI, so make this library available
 ifdef CONFIG_DM_SPI
 obj-y += spi-uclass.o
+obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
 obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o
 obj-$(CONFIG_SOFT_SPI) += soft_spi.o
 obj-$(CONFIG_SPI_MEM) += spi-mem.o

@@ -22,7 +23,6 @@ obj-$(CONFIG_BCM63XX_SPI) += bcm63xx_spi.o
 obj-$(CONFIG_BCMSTB_SPI) += bcmstb_spi.o
 obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o
 obj-$(CONFIG_CF_SPI) += cf_spi.o
-obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
 obj-$(CONFIG_DESIGNWARE_SPI) += designware_spi.o
 obj-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
 obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o

drivers/spi/davinci_spi.c +0 -157

index 4d2c106440..c1646f6cdc 100644
@@ -52,41 +52,6 @@
 /* SPIDEF */
 #define SPIDEF_CSDEF0_MASK     BIT(0)
 
-#ifndef CONFIG_DM_SPI
-#define SPI0_BUS               0
-#define SPI0_BASE              CONFIG_SYS_SPI_BASE
-/*
- * Define default SPI0_NUM_CS as 1 for existing platforms that uses this
- * driver. Platform can configure number of CS using CONFIG_SYS_SPI0_NUM_CS
- * if more than one CS is supported and by defining CONFIG_SYS_SPI0.
- */
-#ifndef CONFIG_SYS_SPI0
-#define SPI0_NUM_CS            1
-#else
-#define SPI0_NUM_CS            CONFIG_SYS_SPI0_NUM_CS
-#endif
-
-/*
- * define CONFIG_SYS_SPI1 when platform has spi-1 device (bus #1) and
- * CONFIG_SYS_SPI1_NUM_CS defines number of CS on this bus
- */
-#ifdef CONFIG_SYS_SPI1
-#define SPI1_BUS               1
-#define SPI1_NUM_CS            CONFIG_SYS_SPI1_NUM_CS
-#define SPI1_BASE              CONFIG_SYS_SPI1_BASE
-#endif
-
-/*
- * define CONFIG_SYS_SPI2 when platform has spi-2 device (bus #2) and
- * CONFIG_SYS_SPI2_NUM_CS defines number of CS on this bus
- */
-#ifdef CONFIG_SYS_SPI2
-#define SPI2_BUS               2
-#define SPI2_NUM_CS            CONFIG_SYS_SPI2_NUM_CS
-#define SPI2_BASE              CONFIG_SYS_SPI2_BASE
-#endif
-#endif
-
 DECLARE_GLOBAL_DATA_PTR;
 
 /* davinci spi register set */

@@ -119,9 +84,6 @@ struct davinci_spi_regs {
 
 /* davinci spi slave */
 struct davinci_spi_slave {
-#ifndef CONFIG_DM_SPI
-       struct spi_slave slave;
-#endif
        struct davinci_spi_regs *regs;
        unsigned int freq; /* current SPI bus frequency */
        unsigned int mode; /* current SPI mode used */

@@ -343,124 +305,6 @@ out:
        return 0;
 }
 
-#ifndef CONFIG_DM_SPI
-
-static inline struct davinci_spi_slave *to_davinci_spi(struct spi_slave *slave)
-{
-       return container_of(slave, struct davinci_spi_slave, slave);
-}
-
-int spi_cs_is_valid(unsigned int bus, unsigned int cs)
-{
-       int ret = 0;
-
-       switch (bus) {
-       case SPI0_BUS:
-               if (cs < SPI0_NUM_CS)
-                       ret = 1;
-               break;
-#ifdef CONFIG_SYS_SPI1
-       case SPI1_BUS:
-               if (cs < SPI1_NUM_CS)
-                       ret = 1;
-               break;
-#endif
-#ifdef CONFIG_SYS_SPI2
-       case SPI2_BUS:
-               if (cs < SPI2_NUM_CS)
-                       ret = 1;
-               break;
-#endif
-       default:
-               /* Invalid bus number. Do nothing */
-               break;
-       }
-       return ret;
-}
-
-void spi_cs_activate(struct spi_slave *slave)
-{
-       /* do nothing */
-}
-
-void spi_cs_deactivate(struct spi_slave *slave)
-{
-       /* do nothing */
-}
-
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
-                       unsigned int max_hz, unsigned int mode)
-{
-       struct davinci_spi_slave        *ds;
-
-       if (!spi_cs_is_valid(bus, cs))
-               return NULL;
-
-       ds = spi_alloc_slave(struct davinci_spi_slave, bus, cs);
-       if (!ds)
-               return NULL;
-
-       switch (bus) {
-       case SPI0_BUS:
-               ds->regs = (struct davinci_spi_regs *)SPI0_BASE;
-               break;
-#ifdef CONFIG_SYS_SPI1
-       case SPI1_BUS:
-               ds->regs = (struct davinci_spi_regs *)SPI1_BASE;
-               break;
-#endif
-#ifdef CONFIG_SYS_SPI2
-       case SPI2_BUS:
-               ds->regs = (struct davinci_spi_regs *)SPI2_BASE;
-               break;
-#endif
-       default: /* Invalid bus number */
-               return NULL;
-       }
-
-       ds->freq = max_hz;
-       ds->mode = mode;
-
-       return &ds->slave;
-}
-
-void spi_free_slave(struct spi_slave *slave)
-{
-       struct davinci_spi_slave *ds = to_davinci_spi(slave);
-
-       free(ds);
-}
-
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
-            const void *dout, void *din, unsigned long flags)
-{
-       struct davinci_spi_slave *ds = to_davinci_spi(slave);
-
-       ds->cur_cs = slave->cs;
-
-       return __davinci_spi_xfer(ds, bitlen, dout, din, flags);
-}
-
-int spi_claim_bus(struct spi_slave *slave)
-{
-       struct davinci_spi_slave *ds = to_davinci_spi(slave);
-
-#ifdef CONFIG_SPI_HALF_DUPLEX
-       ds->half_duplex = true;
-#else
-       ds->half_duplex = false;
-#endif
-       return __davinci_spi_claim_bus(ds, ds->slave.cs);
-}
-
-void spi_release_bus(struct spi_slave *slave)
-{
-       struct davinci_spi_slave *ds = to_davinci_spi(slave);
-
-       __davinci_spi_release_bus(ds);
-}
-
-#else
 static int davinci_spi_set_speed(struct udevice *bus, uint max_hz)
 {
        struct davinci_spi_slave *ds = dev_get_priv(bus);

@@ -579,4 +423,3 @@ U_BOOT_DRIVER(davinci_spi) = {
        .ops = &davinci_spi_ops,
        .priv_auto_alloc_size = sizeof(struct davinci_spi_slave),
 };
-#endif

drivers/spi/spi.c +38 -1

index 22910de0dd..4d1ade797b 100644
@@ -38,3 +38,41 @@ void *spi_do_alloc_slave(int offset, int size, unsigned int bus,
 
        return ptr;
 }
+
+/**
+ * These are non-dm spi core operations, will remove once all driver
+ * converted into full driver model.
+ */
+__weak void spi_cs_activate(struct spi_slave *slave)
+{
+}
+
+__weak void spi_cs_deactivate(struct spi_slave *slave)
+{
+}
+
+__weak struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+                                        unsigned int max_hz,
+                                        unsigned int mode)
+{
+       return NULL;
+}
+
+__weak void spi_free_slave(struct spi_slave *slave)
+{
+}
+
+__weak int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
+                   const void *dout, void *din, unsigned long flags)
+{
+       return 0;
+}
+
+__weak int spi_claim_bus(struct spi_slave *slave)
+{
+       return 0;
+}
+
+__weak void spi_release_bus(struct spi_slave *slave)
+{
+}
--

2.18.0.321.gffc6fa0e3

Quoted 10 lines · Jagan Teki

davinci_spi now support dt along with platform data, respective boards need to switch into dm for the same.

Cc Adam Ford <[email protected]>

Cc Vitaly Andrianov <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Peter Howard <[email protected]>

Cc Tom Rini <[email protected]>

Signed-off-by Jagan Teki <[email protected]>

Jagan,

I tried to apply the entire series against a clean origin/master, but it's not applying cleanly.

Quoted 14 lines · Adam Ford

Quoted 10 lines · Jagan Teki

davinci_spi now support dt along with platform data, respective boards need to switch into dm for the same.

Cc Adam Ford <[email protected]>

Cc Vitaly Andrianov <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Peter Howard <[email protected]>

Cc Tom Rini <[email protected]>

Signed-off-by Jagan Teki <[email protected]>

Quoted 4 lines

Jagan,

I tried to apply the entire series against a clean origin/master, but it's not applying cleanly.

Yeah.. I have few patches before. anyway use spi-dm-migrate branch.

Dropped
- sh_spi driver
- CONFIG_SH_SPI,SH_SPI_BASE

Dropped becuase
- no active updates
- no dm conversion
- multiple pings for asking dm-conversion

- no reponse for dm converted patch
- driver-model migration expiry

On 11/25/2018 06:28 PM, Jagan Teki wrote:

(trimming the insane and utterly useless To: list)

Quoted 8 lines

Dropped
- sh_spi driver
- CONFIG_SH_SPI,SH_SPI_BASE

Dropped becuase
- no active updates
- no dm conversion
- multiple pings for asking dm-conversion

I haven't received a single notification, this is even worse than the horrible botched handling of BLK conversion series.

On 11/25/2018 06:28 PM, Jagan Teki wrote:

(trimming the insane and utterly useless To: list)

Quoted 4 lines

Dropped
- sh_spi driver
- CONFIG_SH_SPI,SH_SPI_BASE

Quoted 4 lines

Dropped becuase
- no active updates
- no dm conversion
- multiple pings for asking dm-conversion

I haven't received a single notification, this is even worse than the horrible botched handling of BLK conversion series.

Quoted 3 lines

- no reponse for dm converted patch
- driver-model migration expiry

NAK, this patch breaks multiple boards which are in active use. The SPL on those boards has size limitations which do not permit DM.

Drop the non-dm code, those board which uses non-dm need to define DM_SPI. u-boot build trigger the warning for the same.

Signed-off-by Jagan Teki <[email protected]>

---
 Makefile                |   2 +-
 drivers/spi/Makefile    |   2 +-
 drivers/spi/omap3_spi.c | 126 ----------------------------------------
 3 files changed, 2 insertions(+), 128 deletions(-)

Makefile +1 -1

index 3be3bb3118..00f0117b16 100644
@@ -920,7 +920,7 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y)
 endif
 ifeq ($(CONFIG_DM_SPI),)
 ifeq ($(filter $(CONFIG_DAVINCI_SPI) $(CONFIG_KIRKWOOD_SPI) $(CONFIG_MPC8XXX_SPI) \
-              $(CONFIG_MXC_SPI) $(CONFIG_TI_QSPI),y),y)
+              $(CONFIG_MXC_SPI) $(CONFIG_OMAP3_SPI) $(CONFIG_TI_QSPI),y),y)
        @echo "===================== WARNING ======================"
        @echo "This board uses SPI driver from drivers/spi/ without"
        @echo "enabling CONFIG_DM_SPI. Please enable CONFIG_DM_SPI"

drivers/spi/Makefile +1 -1

index c682b014e7..6b8b92434c 100644
@@ -10,6 +10,7 @@ obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
 obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
 obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
 obj-$(CONFIG_MXC_SPI) += mxc_spi.o
+obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o
 obj-$(CONFIG_SOFT_SPI) += soft_spi.o
 obj-$(CONFIG_SPI_MEM) += spi-mem.o

@@ -35,7 +36,6 @@ obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
 obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
 obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
 obj-$(CONFIG_ATCSPI200_SPI) += atcspi200_spi.o
-obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 obj-$(CONFIG_PIC32_SPI) += pic32_spi.o
 obj-$(CONFIG_PL022_SPI) += pl022_spi.o
 obj-$(CONFIG_RENESAS_RPC_SPI) += renesas_rpc_spi.o

drivers/spi/omap3_spi.c +0 -127

index c7fcf050a5..5e267d88d7 100644
@@ -108,9 +108,6 @@ struct mcspi {
 };
 
 struct omap3_spi_priv {
-#ifndef CONFIG_DM_SPI
-       struct spi_slave slave;
-#endif
        struct mcspi *regs;
        unsigned int cs;
        unsigned int freq;

@@ -454,128 +451,6 @@ static void _omap3_spi_claim_bus(struct omap3_spi_priv *priv)
        writel(conf, &priv->regs->modulctrl);
 }
 
-#ifndef CONFIG_DM_SPI
-
-static inline struct omap3_spi_priv *to_omap3_spi(struct spi_slave *slave)
-{
-       return container_of(slave, struct omap3_spi_priv, slave);
-}
-
-void spi_free_slave(struct spi_slave *slave)
-{
-       struct omap3_spi_priv *priv = to_omap3_spi(slave);
-
-       free(priv);
-}
-
-int spi_claim_bus(struct spi_slave *slave)
-{
-       struct omap3_spi_priv *priv = to_omap3_spi(slave);
-
-       spi_reset(priv->regs);
-
-       _omap3_spi_claim_bus(priv);
-       _omap3_spi_set_wordlen(priv);
-       _omap3_spi_set_mode(priv);
-       _omap3_spi_set_speed(priv);
-
-       return 0;
-}
-
-void spi_release_bus(struct spi_slave *slave)
-{
-       struct omap3_spi_priv *priv = to_omap3_spi(slave);
-
-       writel(OMAP3_MCSPI_MODULCTRL_MS, &priv->regs->modulctrl);
-}
-
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
-                                    unsigned int max_hz, unsigned int mode)
-{
-       struct omap3_spi_priv *priv;
-       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;
-       }
-
-       priv = spi_alloc_slave(struct omap3_spi_priv, bus, cs);
-       if (!priv) {
-               printf("SPI error: malloc of SPI structure failed\n");
-               return NULL;
-       }
-
-       priv->regs = regs;
-       priv->cs = cs;
-       priv->freq = max_hz;
-       priv->mode = mode;
-       priv->wordlen = priv->slave.wordlen;
-#if 0
-       /* Please migrate to DM_SPI support for this feature. */
-       priv->pin_dir = MCSPI_PINDIR_D0_OUT_D1_IN;
-#endif
-
-       return &priv->slave;
-}
-
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
-            const void *dout, void *din, unsigned long flags)
-{
-       struct omap3_spi_priv *priv = to_omap3_spi(slave);
-
-       return _spi_xfer(priv, bitlen, dout, din, flags);
-}
-
-#else
-
 static int omap3_spi_claim_bus(struct udevice *dev)
 {
        struct udevice *bus = dev->parent;

@@ -700,4 +575,3 @@ U_BOOT_DRIVER(omap3_spi) = {
        .ops    = &omap3_spi_ops,
        .priv_auto_alloc_size = sizeof(struct omap3_spi_priv),
 };
-#endif
--

2.18.0.321.gffc6fa0e3

Update the spi driver dm-conversion status.

Signed-off-by Jagan Teki <[email protected]>

---
 doc/driver-model/MIGRATION.txt | 18 +-----------------
 1 file changed, 1 insertion(+), 17 deletions(-)

-----Original Message-----
From: Jagan Teki [mailto:jagan at amarulasolutions.com]
Sent: 2018年11月26日 1:28
To: Adam Ford <[email protected]>; Vitaly Andrianov <[email protected]>; Stefano Babic <[email protected]>; Peter Howard <[email protected]>; Tom Rini <[email protected]>; Walter Schweizer <[email protected]>; Valentin Longchamp <[email protected]>; Phil Sutter <[email protected]>; Stefan Roese <[email protected]>; Simon Glass <[email protected]>; Tuomas Tynkkynen <[email protected]>; Sam Protsenko <[email protected]>; Dirk Eibach <[email protected]>; Mario Six <[email protected]>; Simon Guinot <[email protected]>; Konstantin Porotchkin <[email protected]>; Jason Cooper <[email protected]>; Marek Behún <[email protected]>; Lokesh Vutla <[email protected]>; Andrew F . Davis <[email protected]>; Uri Mashiach <[email protected]>; Heiko Schocher <[email protected]>; Tc Liew <[email protected]>; Joe Hershberger <[email protected]>; Angelo Dureghello <[email protected]>; Vladimir Zapolskiy <[email protected]>; Albert ARIBAUD <[email protected]>; Marek Vasut <[email protected]>; Fabio Estevam <[email protected]>; Nikita Kiryanov <[email protected]>; Lukasz Majewski <[email protected]>; Markus Niebel <[email protected]>; Troy Kisky <[email protected]>; Akshay Bhat <[email protected]>; Ken Lin <[email protected]>; Peng Fan <[email protected]>; Magnus Lilja <[email protected]>; Christian Gmeiner <[email protected]>; Eric Bénard <[email protected]>; Ian Ray <[email protected]>; Otavio Salvador <[email protected]>; Andreas Geisreiter <[email protected]>; Ludwig Zenz <[email protected]>; Dmitry Lifshitz <[email protected]>; Roger Meier <[email protected]>; Gilles Gameiro <[email protected]>; Lothar Felten <[email protected]>; Tapani Utriainen <[email protected]>; Steve Sakoman <[email protected]>; Pali Rohár <[email protected]>; Marcin Niestroj <[email protected]>; Nishanth Menon <[email protected]>; Lars Poeschel <[email protected]>; Enric Balletbo i Serra <[email protected]>; Yegor Yefremov <[email protected]>; Ash Charles <[email protected]>; Grazvydas Ignotas <[email protected]>; Igor Grinberg <[email protected]>; Derald D . Woods <[email protected]>; Hannes Schmelzer <[email protected]>; Eugen Hristev <[email protected]>; Ludovic Desroches <[email protected]>; Stelian Pop <[email protected]>; Mateusz Kulikowski <[email protected]>; Ilko Iliev <[email protected]>; Daniel Gorsulowski <[email protected]>; Ben Whitten <[email protected]>; Andreas Bießmann <[email protected]>; Erik van Luijk <[email protected]>; Gregory CLEMENT <[email protected]>; Prabhakar Kushwaha <[email protected]>; Sumit Garg <[email protected]>; York Sun <[email protected]>; Yinbo Zhu <[email protected]>; Priyanka Jain <[email protected]>; Mingkai Hu <[email protected]>; Alison Wang <[email protected]>; Ashish Kumar <[email protected]>; Udit Agarwal <[email protected]>; VINITHA V PILLAI <[email protected]>; Feng Li <[email protected]>; Qiang Zhao <[email protected]>; Naveen Burmi <[email protected]>; Shengzhou Liu <[email protected]>; Ruchika Gupta <[email protected]>; Poonam Aggrwal <[email protected]>; Timur Tabi <[email protected]>; Xiaobo Xie <[email protected]>; PO LIU <[email protected]>
Cc: u-boot at lists.denx.de; Jagan Teki <[email protected]>
Subject: [PATCH v2 00/32] spi: DM_SPI migration timeout, remainder(2)

This series fix, build issues and comments from previous series [1].

We have not heard any positive feed back about dm-conversion on spi drivers along with no response for the work done by Akash and me.

Plan is to send the same series remainder recursively based on the dm conversion updates and finally merged into v2019.04 MW.

So expecting inputs from relevant developers to move their board/drivers to support DM_SPI.

- cf_spi, lpc32xx_ssp, mxs_spi, sh_spi, soft_spi_legacy, fsl_espi drivers are drooped with their respective CONFIG items.
the spi/spi-flash usage commands still build but the used spi core function calls return 0.
- non-dm code in davinci, kirkwood, ti_qspi, mpc8xxx, mxc, omap3, atmel, fsl_dspi drivers were drooped and u-boot build system will trigger warning for the same.

Note:
- Let's discuss if any foot-print issues?

Any inputs,
Jagan.

[1]
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
hwork.ozlabs.org%2Fcover%2F1000444%2F&amp;data=02%7C01%7Cpeng.fa n%40nxp.com%7C575d95c25be74fc237bb08d652fb8b34%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C636787637664212094&amp;sdata=Wy H54iAVB%2BRPIVvgpQsw1T3cG5UUtNRKbFR08wibgOg%3D&amp;reserved= 0

Jagan Teki (15):
spi: davinci: Full dm conversion
spi: kirkwood: Full dm conversion
spi: ti_qspi: Full dm conversion
spi: mpc8xxx: Convert to DM
spi: Zap cf_spi driver-related code
spi: Zap lpc32xx_ssp driver-related code
spi: Zap mxs_spi driver-related code
spi: Zap sh_spi driver-related code
spi: Zap soft_spi_legacy driver-related code
spi: mxc: Drop non-dm code
spi: omap3: Drop non-dm code
spi: atmel: Drop non-dm code
spi: Zap fsl_espi driver-related code
spi: fsl_dspi: Drop non-dm code
dm: MIGRATION: spi: Update SPI driver status

Mario Six (17):
spi: mpc8xxx: Use short type names
spi: mpc8xxx: Fix comments
spi: mpc8xxx: Rename camel-case variables
spi: mpc8xxx: Fix space after cast
spi: mpc8xxx: Fix function names in strings
spi: mpc8xxx: Replace defines with enums
spi: mpc8xxx: Use IO accessors
spi: mpc8xxx: Simplify if
spi: mpc8xxx: Get rid of is_read
spi: mpc8xxx: Simplify logic a bit
spi: mpc8xxx: Reduce scope of loop variables
spi: mpc8xxx: Make code more readable
spi: mpc8xxx: Rename variable
spi: mpc8xxx: Document LEN setting better
spi: mpc8xxx: Re-order transfer setup
spi: mpc8xxx: Fix if check
spi: mpc8xxx: Use get_timer

 Makefile                                      |  11 +
 arch/m68k/cpu/mcf5227x/cpu_init.c             |  54 --
 arch/m68k/cpu/mcf5445x/cpu_init.c             | 113 ----
 board/Arcturus/ucp1020/ucp1020.c              |   6 +
 configs/M52277EVB_defconfig                   |   1 -
 configs/M52277EVB_stmicro_defconfig           |   1 -
 configs/M54418TWR_defconfig                   |   1 -
 configs/M54418TWR_nand_mii_defconfig          |   1 -
 configs/M54418TWR_nand_rmii_defconfig         |   1 -
 configs/M54418TWR_nand_rmii_lowfreq_defconfig |   1 -
 configs/M54418TWR_serial_mii_defconfig        |   1 -
 configs/M54418TWR_serial_rmii_defconfig       |   1 -
 configs/M54451EVB_defconfig                   |   1 -
 configs/M54451EVB_stmicro_defconfig           |   1 -
 configs/M54455EVB_a66_defconfig               |   1 -
 configs/M54455EVB_defconfig                   |   1 -
 configs/M54455EVB_i66_defconfig               |   1 -
 configs/M54455EVB_intel_defconfig             |   1 -
 configs/M54455EVB_stm33_defconfig             |   1 -
 configs/bg0900_defconfig                      |   1 -
 configs/devkit3250_defconfig                  |   1 -
 configs/mx28evk_auart_console_defconfig       |   1 -
 configs/mx28evk_defconfig                     |   1 -
 configs/mx28evk_nand_defconfig                |   1 -
 configs/mx28evk_spi_defconfig                 |   1 -
 configs/sh7752evb_defconfig                   |   1 -
 configs/sh7753evb_defconfig                   |   1 -
 configs/sh7757lcr_defconfig                   |   1 -
 configs/stmark2_defconfig                     |   1 -
 configs/work_92105_defconfig                  |   1 -
 doc/driver-model/MIGRATION.txt                |  18 +-
 drivers/spi/Kconfig                           |  42 +-
 drivers/spi/Makefile                          |  22 +-
 drivers/spi/atmel_spi.c                       | 198 -------
 drivers/spi/cf_spi.c                          | 335 ------------
 drivers/spi/davinci_spi.c                     | 157 ------
 drivers/spi/fsl_dspi.c                        | 132 -----
 drivers/spi/fsl_espi.c                        | 383 --------------
 drivers/spi/kirkwood_spi.c                    | 218 ++------
 drivers/spi/lpc32xx_ssp.c                     | 134 -----
 drivers/spi/mpc8xxx_spi.c                     | 279 ++++++----
 drivers/spi/mxc_spi.c                         | 123 +----
 drivers/spi/mxs_spi.c                         | 358 -------------
 drivers/spi/omap3_spi.c                       | 126 -----
 drivers/spi/sh_spi.c                          | 249 ---------
 drivers/spi/sh_spi.h                          |  67 ---
 drivers/spi/soft_spi_legacy.c                 | 168 ------
 drivers/spi/spi.c                             |  38 ++
 drivers/spi/ti_qspi.c                         | 490 +++++++-----------
 include/configs/M52277EVB.h                   |   1 -
 include/configs/M54418TWR.h                   |   1 -
 include/configs/M54451EVB.h                   |   1 -
 include/configs/M54455EVB.h                   |   1 -
 include/configs/MPC8349EMDS.h                 |   3 -
 include/configs/devkit3250.h                  |   5 -
 include/configs/sh7752evb.h                   |   3 -
 include/configs/sh7753evb.h                   |   3 -
 include/configs/sh7757lcr.h                   |   3 -
 include/configs/stmark2.h                     |   1 -
 include/configs/work_92105.h                  |   5 -
 include/configs/zipitz2.h                     |   1 -
 include/dm/platform_data/spi_kirkwood.h       |  15 +
 include/dm/platform_data/spi_ti_qspi.h        |  19 +
 scripts/config_whitelist.txt                  |   3 -
 64 files changed, 502 insertions(+), 3310 deletions(-)  delete mode 100644

drivers/spi/cf_spi.c delete mode 100644 drivers/spi/fsl_espi.c delete mode 100644 drivers/spi/lpc32xx_ssp.c delete mode 100644 drivers/spi/mxs_spi.c delete mode 100644 drivers/spi/sh_spi.c delete mode 100644 drivers/spi/sh_spi.h delete mode 100644 drivers/spi/soft_spi_legacy.c create mode 100644 include/dm/platform_data/spi_kirkwood.h

 create mode 100644 include/dm/platform_data/spi_ti_qspi.h

--
2.18.0.321.gffc6fa0e3

Hi Jagan,

Just have a quick question here.

After dropping non-DM code, for SPL use non-DM code should switch to SPL_DM and use SPL OF CONTROL?

Quoted 6 lines · Peng Fan

Hi Jagan,

Just have a quick question here.

After dropping non-DM code, for SPL use non-DM code should switch to SPL_DM and use SPL OF CONTROL?

Here are the options, that we dealt based on the size constraints
1) try to use DM_SPL with SPL OF_CONTROL

2) try PLATDATA

3) try TPL for truly small size

if none works, we can see the other option. may be some glue code to read flash for SPL or something else.

Quoted 10 lines · Peng Fan

Quoted 6 lines

Hi Jagan,

Just have a quick question here.

After dropping non-DM code, for SPL use non-DM code should switch to SPL_DM and use SPL OF CONTROL?

Here are the options, that we dealt based on the size constraints
1) try to use DM_SPL with SPL OF_CONTROL

Not possible

Quoted 1 line

2) try PLATDATA

Adds extra bloat to SPLs which are already borderline, so not possible.

Quoted 1 line

3) try TPL for truly small size

How would that help ? I don't need extra level of bootloader, I can use SPL right now.

Quoted 2 lines

if none works, we can see the other option. may be some glue code to read flash for SPL or something else.

I'll have to take a look at the Renesas Gen2, but probably next year.

Hello Marek, Jagan,

Am 27.11.2018 um 13:10 schrieb Marek Vasut:

Quoted 14 lines · Jagan Teki

Quoted 10 lines · Peng Fan

Quoted 6 lines

Hi Jagan,

Just have a quick question here.

After dropping non-DM code, for SPL use non-DM code should switch to SPL_DM and use SPL OF CONTROL?

Here are the options, that we dealt based on the size constraints
1) try to use DM_SPL with SPL OF_CONTROL

Not possible

Quoted 8 lines

Quoted 1 line

2) try PLATDATA

Adds extra bloat to SPLs which are already borderline, so not possible.

Quoted 1 line

3) try TPL for truly small size

How would that help ? I don't need extra level of bootloader, I can use SPL right now.

Exactly my thoughts too. I have a at91 based board (smartweb) in mainline where the SPL fits into 4k sram ... no chance for 1) or 2) ...

I see the reasons for integrating more and more stuff into SPL, but it should be possible to build a small SPL ...

Hopefully TPL stays really small ...

Hmm.. while writting (did not actually looked into TPL ...):

Is it possible to boot U-boot directly from TPL ?

Quoted 4 lines

Quoted 2 lines

if none works, we can see the other option. may be some glue code to read flash for SPL or something else.

I'll have to take a look at the Renesas Gen2, but probably next year.

I talk with customers to get time for converting, but this also may take some time ...

Quoted 6 lines · Peng Fan

Hi Jagan,

Just have a quick question here.

After dropping non-DM code, for SPL use non-DM code should switch to SPL_DM and use SPL OF CONTROL?

Here are the options, that we dealt based on the size constraints
1) try to use DM_SPL with SPL OF_CONTROL

2) try PLATDATA

3) try TPL for truly small size

if none works, we can see the other option. may be some glue code to read flash for SPL or something else.

Hi Jagan,

(CCing the world looks to me quite a terror attack, nevertheless):

Quoted 8 lines · Jagan Teki

Quoted 6 lines · Peng Fan

Hi Jagan,

Just have a quick question here.

After dropping non-DM code, for SPL use non-DM code should switch to SPL_DM and use SPL OF CONTROL?

I can understand the reasons to switch completely to DM code, but let's face some real facts:

- dropping legacy code requires to use SPL_OF_CONTROL into SPL, and yes, footprint steadily increases. We are getting rid of place for MX6 Solo, and this is not an ancient processor we can forget.
Size of SRAM is not something we can discuss - it is. Other features (secure boot, etc.) were pushed to SPL, and these features were requested by real projects. We cannot get rid of these feature just to make place for DM.

- the benefits cannot be really understood by the manufacturers or owners of boards, because they can see a step in the past if they have to forget some features they are currently using.

- TPL adds an additional step and this increases the boottime - another *real* and *important* feature for most projects.

Quoted 2 lines

Here are the options, that we dealt based on the size constraints
1) try to use DM_SPL with SPL OF_CONTROL

There is no enough place for most SOCs, even quite recent. This is not due just to the size of SRAM, but also by some restriction on the usage of the SRAM itself by the internal BootROM.

Quoted 1 line

2) try PLATDATA

This is even not footprint friendly.

Quoted 1 line

3) try TPL for truly small size

See above. There is an additional layer without evident advantages for manufacturers and / or customers.

Quoted 17 lines · Stefano Babic

Hi Jagan,

(CCing the world looks to me quite a terror attack, nevertheless):

Quoted 8 lines · Jagan Teki

Quoted 6 lines · Peng Fan

Hi Jagan,

Just have a quick question here.

After dropping non-DM code, for SPL use non-DM code should switch to SPL_DM and use SPL OF CONTROL?

I can understand the reasons to switch completely to DM code, but let's face some real facts:

Quoted 7 lines

- dropping legacy code requires to use SPL_OF_CONTROL into SPL, and yes, footprint steadily increases. We are getting rid of place for MX6 Solo, and this is not an ancient processor we can forget.
Size of SRAM is not something we can discuss - it is. Other features (secure boot, etc.) were pushed to SPL, and these features were requested by real projects. We cannot get rid of these feature just to make place for DM.

Just what is the limit on MX6 Solo, worst case?

And what boot methods
do we have to support there too?

The am335x with secure boot case is
small, but might not be as small as you have to worry about here.

Quoted 4 lines

- the benefits cannot be really understood by the manufacturers or owners of boards, because they can see a step in the past if they have to forget some features they are currently using.

Yes, we need to make sure that we don't just drop functionality for no apparent reason.

But we can't use that as a reason to maintain wholly
separate subsystems for some platforms either.

Quoted 3 lines

- TPL adds an additional step and this increases the boottime - another *real* and *important* feature for most projects.

I _really_ want to see this measured so we know what time is being added so we can think about what to do about it, too. Yes, adding a few kilobytes is a few cycles, and a few is more than zero, and there are use cases that have demands screaming for less cycles to be used, not more (aside, when this is coupled with "But we're moving to aarch64" and that requires more firmware layers makes me shake my head internally a little). But by that same token, part of the notion behind TPL->SPL->U-Boot or Linux is that some functionality is moved from SPL to TPL.

Quoted 7 lines

Quoted 3 lines

Here are the options, that we dealt based on the size constraints
1) try to use DM_SPL with SPL OF_CONTROL

There is no enough place for most SOCs, even quite recent. This is not due just to the size of SRAM, but also by some restriction on the usage of the SRAM itself by the internal BootROM.

This is debatable, frankly. But yes, we do have modern platforms with a still small usable by first non-ROM-application amount of memory. So we must have a solution.

Quoted 4 lines

Quoted 2 lines

2) try PLATDATA

This is even not footprint friendly.

Why? This is in fact our current method for "we need something more footprint friendly to feed enough info in to get to the next application".

Quoted 5 lines

Quoted 2 lines

3) try TPL for truly small size

See above. There is an additional layer without evident advantages for manufacturers and / or customers.

"You need this in order to boot now". Just like moving from say DCD files to SPL required convincing manufacturers and customers that it was a win even if you could do everything with DCD scripts and plugins, this too requires explanation.

But also, I keep saying, and it feels like I keep not being heard, we aren't declaring the death of non-DM for SPL for all platforms just yet.

There's likely a few more technical challenges to sort out, and some explanation of why the world isn't static required before we can do that.

Hi Tom,

Quoted 26 lines · Tom Rini

Quoted 24 lines · Stefano Babic

Hi Jagan,

(CCing the world looks to me quite a terror attack, nevertheless):

Quoted 8 lines · Jagan Teki

Quoted 6 lines · Peng Fan

Hi Jagan,

Just have a quick question here.

After dropping non-DM code, for SPL use non-DM code should switch to SPL_DM and use SPL OF CONTROL?

I can understand the reasons to switch completely to DM code, but let's face some real facts:

- dropping legacy code requires to use SPL_OF_CONTROL into SPL, and yes, footprint steadily increases. We are getting rid of place for MX6 Solo, and this is not an ancient processor we can forget.
Size of SRAM is not something we can discuss - it is. Other features (secure boot, etc.) were pushed to SPL, and these features were requested by real projects. We cannot get rid of these feature just to make place for DM.

Quoted 1 line

Just what is the limit on MX6 Solo, worst case?

Solo has 68KB OCRAM available - if I remember well, letting some space for early stack and some other thigs, there is still 49K available. This was big enough when SPL was ported to MX, now we are approaching the limit.

This is worst when for some projects there is the need for some customization, like additional code to get device data or calibration for RAM. In some cases, it is becoming tricky.

Anyway, my concern is that the OCRAM is not so small, but nevertheless we have now reached the point where the SPL has grown so much to take all available size.

Quoted 2 lines

And what boot methods
do we have to support there too?

I can imagine that at least booting from storages (NAND, SPI, SD) and from SDP (usb gadget) should be supported in the same SPL. Maybe just a couple of storages at the same time (main boot device and "backup" to restore it).

Quoted 2 lines

The am335x with secure boot case is
small, but might not be as small as you have to worry about here.

It looks to me that size is quite comparable to AM335x.

Quoted 7 lines

Quoted 4 lines

- the benefits cannot be really understood by the manufacturers or owners of boards, because they can see a step in the past if they have to forget some features they are currently using.

Yes, we need to make sure that we don't just drop functionality for no apparent reason.

Fully agree.

Quoted 2 lines

But we can't use that as a reason to maintain wholly
separate subsystems for some platforms either.

Right, but we have to find a solution.

Quoted 12 lines

Quoted 2 lines

- TPL adds an additional step and this increases the boottime - another *real* and *important* feature for most projects.

I _really_ want to see this measured so we know what time is being added so we can think about what to do about it, too. Yes, adding a few kilobytes is a few cycles, and a few is more than zero, and there are use cases that have demands screaming for less cycles to be used, not more (aside, when this is coupled with "But we're moving to aarch64" and that requires more firmware layers makes me shake my head internally a little). But by that same token, part of the notion behind TPL->SPL->U-Boot or Linux is that some functionality is moved from SPL to TPL.

I have no measures - this can be done after moving one of these i.MX6 to

a TPL based bootloader. I am just thinking about when we introduced SPL some years ago. One goal was to have a "simpler" loader that provides the first initialization (just RAM and console), letting u-boot to do the rest. This sounds weird now - these are the requirement we ask for TPL. So TPL looks to me an early SPL - can we just have a simpler SPL, that just does the simple initialization ? TPL was initially thought for SOCs having a very small RAM on board, and then they can boot from a single storage only. This is also not the requirement for more complex SOC, and even with TPL, a i.MX should boot from SPI, NAND / SD. And to maintain the trust of chain, TPL should able to load just signed images, too (it is another step and add complexity).

For aarch64, I agree with you and there is nothing we can do against it. More layers were also introduced due to increased requirements for security.On the other side, these SOCs could be faster during boot due to better CPU.

What about the drivers we need in TPL ? They cannot be a DM driver, so we still need some legacy drivers for storage. We should still have both type of drivers (DM and not DM), and dropping current legacy drivers from SPL does not help.

Quoted 10 lines

Quoted 6 lines

Quoted 2 lines

Here are the options, that we dealt based on the size constraints
1) try to use DM_SPL with SPL OF_CONTROL

There is no enough place for most SOCs, even quite recent. This is not due just to the size of SRAM, but also by some restriction on the usage of the SRAM itself by the internal BootROM.

This is debatable, frankly. But yes, we do have modern platforms with a still small usable by first non-ROM-application amount of memory. So we must have a solution.

Fully agree.

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

2) try PLATDATA

Quoted 5 lines

Quoted 1 line

This is even not footprint friendly.

Why? This is in fact our current method for "we need something more footprint friendly to feed enough info in to get to the next application".

I think I need some measure - if size remains small enough, it could be a suitable way.

Quoted 9 lines

Quoted 4 lines

Quoted 1 line

3) try TPL for truly small size

See above. There is an additional layer without evident advantages for manufacturers and / or customers.

"You need this in order to boot now". Just like moving from say DCD files to SPL required convincing manufacturers and customers that it was a win even if you could do everything with DCD scripts and plugins, this too requires explanation.

I agree - but let's me say that the advantages in that case were very clear (no fixed RAM setup bound to the HW, run time detection, single binary for multiple variants in case of i.MX6,..) and most important, these advantages meant for manufacturers less costs. Less cost because it is easier to relace a chip that reached EOL, or because they do not have different part number for each bootloader (they have just one), or...

The same should happens now to convince again manufacturers and customers.

Quoted 3 lines

But also, I keep saying, and it feels like I keep not being heard, we aren't declaring the death of non-DM for SPL for all platforms just yet.

Nice to listen this - I was already scared from this thread and last "CONFIG_BLK" :-)

Quoted 3 lines

There's likely a few more technical challenges to sort out, and some explanation of why the world isn't static required before we can do that.