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@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@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@gateworks.com Signed-off-by: Tom Rini trini@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.
- 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...
- 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.
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.