[PATCH 16/25] arm: Remove gwventana boards

[Tim Harvey]

On Wed, Feb 17, 2021 at 10:35 AM Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Feb 17, 2021 at 10:26:20AM -0800, Tim Harvey wrote:
> > On Wed, Feb 10, 2021 at 9:31 AM Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Wed, Feb 10, 2021 at 09:29:44AM -0800, Tim Harvey wrote:
> > > > On Tue, Feb 9, 2021 at 5:03 AM Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > These boards have not been converted to CONFIG_DM_MMC by the deadline of
> > > > > v2019.04, which is almost two years ago.  In addition there are other DM
> > > > > migrations it is also missing.  Remove them.
> > > > >
> > > > > Cc: Tim Harvey <tharvey at gateworks.com>
> > > > > Signed-off-by: Tom Rini <trini at konsulko.com>
> > > > > ---
> > > > >  arch/arm/mach-imx/mx6/Kconfig               |    1 -
> > > > >  board/gateworks/gw_ventana/Kconfig          |   28 -
> > > > >  board/gateworks/gw_ventana/MAINTAINERS      |    8 -
> > > > >  board/gateworks/gw_ventana/Makefile         |   11 -
> > > > >  board/gateworks/gw_ventana/README           |  320 ----
> > > > >  board/gateworks/gw_ventana/common.c         | 1760 -------------------
> > > > >  board/gateworks/gw_ventana/common.h         |   99 --
> > > > >  board/gateworks/gw_ventana/eeprom.c         |  266 ---
> > > > >  board/gateworks/gw_ventana/gsc.c            |  283 ---
> > > > >  board/gateworks/gw_ventana/gsc.h            |   71 -
> > > > >  board/gateworks/gw_ventana/gw_ventana.c     | 1381 ---------------
> > > > >  board/gateworks/gw_ventana/gw_ventana_spl.c |  779 --------
> > > > >  board/gateworks/gw_ventana/ventana_eeprom.h |  140 --
> > > > >  configs/gwventana_emmc_defconfig            |  111 --
> > > > >  configs/gwventana_gw5904_defconfig          |  115 --
> > > > >  configs/gwventana_nand_defconfig            |  115 --
> > > > >  include/configs/gw_ventana.h                |  298 ----
> > > > >  17 files changed, 5786 deletions(-)
> > > > >  delete mode 100644 board/gateworks/gw_ventana/Kconfig
> > > > >  delete mode 100644 board/gateworks/gw_ventana/MAINTAINERS
> > > > >  delete mode 100644 board/gateworks/gw_ventana/Makefile
> > > > >  delete mode 100644 board/gateworks/gw_ventana/README
> > > > >  delete mode 100644 board/gateworks/gw_ventana/common.c
> > > > >  delete mode 100644 board/gateworks/gw_ventana/common.h
> > > > >  delete mode 100644 board/gateworks/gw_ventana/eeprom.c
> > > > >  delete mode 100644 board/gateworks/gw_ventana/gsc.c
> > > > >  delete mode 100644 board/gateworks/gw_ventana/gsc.h
> > > > >  delete mode 100644 board/gateworks/gw_ventana/gw_ventana.c
> > > > >  delete mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c
> > > > >  delete mode 100644 board/gateworks/gw_ventana/ventana_eeprom.h
> > > > >  delete mode 100644 configs/gwventana_emmc_defconfig
> > > > >  delete mode 100644 configs/gwventana_gw5904_defconfig
> > > > >  delete mode 100644 configs/gwventana_nand_defconfig
> > > > >  delete mode 100644 include/configs/gw_ventana.h
> > > > >
> > > >
> > > > Tom,
> > > >
> > > > I will submit a patchset to convert the gw_ventana IMX6 based boards
> > > > to DM. I started this effort over a year ago and got stuck at some
> > > > point but I think I know how to get through that now.
> > > >
> > > > I hope to be able to submit something by the end of next week.
> > >
> > > Thanks!  Their conversion will help unblock a few of the older
> > > migrations.
> >
> > Tom / Stefano,
> >
> > Looking at this again I realize where I got stuck previously trying to
> > migrate the Gateworks Ventana support to driver-model.
>
> Thanks for digging in and summarizing.
>
> > 1. I need MULTI_DTB_FIT for raw NAND and the following issues are blocking me:
> >   a. spl_nand_fit_read() requires the reads to be page-aligned to the
> > writesize of the NAND device. I have to work through trying to give
> > the common nand spl code knowledge of the mtd device to get around
> > this.
> >   b. spl_nand_fit_read() since 9f6a14c47ff9 ("spl: fit: nand: fix fit
> > loading in case of bad blocks") which introduces bad block handling
> > now requires a lot of static defines describing the NAND chip such as
> > CONFIG_SYS_NAND_BLOCK_SIZE CONFIG_SYS_NAND_BAD_BLOCK_POS and a few
> > more that I need to get from mtd as well as we support multiple flash
> > devices that have different geometries. I can wrap that code around an
> > 'ifdef CONFIG_SYS_NAND_BLOCK_SIZE' to opt out of that feature.
>
> Which is all SPL related, right?  It seems so, but to be clear...
>

Yes, both issues above are with regards to imx SPL+FIT+NAND.
Ironically if I could use driver-model for SPL it would make things
much easier working around what I ran into.

> > 2. I have a board with an MV88E61XX switch and
> > drivers/net/phy/mv88e61xx.c and I don't see any driver-model support
> > for eth switches connected to a phy. This blocks me from using DM_ETH.
> > I have an unsubmitted patch queued up depending on my imx8mm-venice
> > series that I think may provide a dm solution for network switches via
> > DM_ETH_PHY.
> > 3. I can't use driver model for SPL because of memory constraints: I
> > need to read the board model from an I2C EEPROM in the SPL and then if
> > I wanted to use SPL dm I would have to use dm_uninit() followed by
> > dm_init_and_scan() which doesn't work because dm_uninit() does not
> > free memory. It seems to me the DM_SPL code needs to implement memory
> > free.
> >
> > The biggest hurdle I see is (3) above and as far as I can tell most if
> > not all other IMX boards are not using driver model for SPL. If this
> > is true, then there are a lot of boards out there that haven't been
> > able to fully swtich to driver model and are getting missed in the
> > checks because DM_USB, DM_MMC, DM_* are defined for U-boot proper.
> > That does not help remove legacy code from what I can tell.
> >
> > What are your thoughts on the fact that many (majority?) boards are
> > still using non-dm code for SPL?
>
> So, SPL in DM is not a general requirement.  There's some new features
> in SPL that aren't available without it, but if you aren't using them
> today, that's not a big problem.

Ok... I just thought it was strange that there was this big push to
get all MMC to DM_MMC yet the non-dm mmc code still seems to be needed
for all the boards using non-dm SPL.

>
> That leaves DM_ETH, which has a deadline of v2020.07 (so just barely
> past) and since you're on the way to hopefully addressing the general
> problem, that's great.  My big concern right now is all of the
> v2019.04/07 deadlines.  If you can address those right now, that's
> great.

I should be able to address that. Hopefully I'll have a patch series
submitted soon.

Thanks,

Tim