On 02/03/2017 11:23 AM, Tom Rini wrote: > On Fri, Feb 03, 2017 at 09:57:03AM +0530, Vignesh R wrote: >> >> >> On Friday 03 February 2017 03:48 AM, Strashko, Grygorii wrote: >>> Convert OMAP hsmmc driver to use driver-model block devices. >>> >>> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com> >>> --- >>> Hi All, >>> >>> First of all, sorry if my questions/problems are looks dumb, I'm very new >>> with u-boot. >>> >>> This is my attampt to enable CONFIG_BLK on OMAP platforms which is blocked >>> now >>> by omap_hsmmc driver. omap_hsmmc required to be updated to use driver-model >>> block >>> devices at minimum (and max to use dm_mmc_ops). Also, as per my >>> understanding, >>> CONFIG_BLK is blocker for other tasks like enabling driver model for OMAP >>> sata devices. >>> >>> With this patch I can boot from mmc on am335x-evm, but there are >>> two problems I need help with: >>> 1) My changes in Makefiles looks really ugly, but without them SPL build >>> will >>> fail because undef'ing in include/configs/am335x_evm.h does not take >>> effect >>> in Makefile (thanks Vignesh for the information [1]) and I, honestly, do >>> not >>> know how to fix it in better way, so I'd be appreciated for any help. >>> Comparing to Vignesh's case, files which need to be excluded from build >>> are generic and I worry that there can be dependecy from CONFIG_SPL_DM. >>> >> >>> >>> diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig >>> index 6f624e9..d36e7d4 100644 >>> --- a/configs/am335x_evm_defconfig >>> +++ b/configs/am335x_evm_defconfig >>> @@ -30,7 +30,6 @@ CONFIG_CMD_GPIO=y >>> CONFIG_CMD_EXT4_WRITE=y >>> CONFIG_OF_CONTROL=y >>> CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk >>> am335x-bonegreen am335x-icev2" >>> -# CONFIG_BLK is not set >>> CONFIG_DFU_MMC=y >>> CONFIG_DFU_NAND=y >>> CONFIG_DFU_RAM=y >>> diff --git a/drivers/block/Makefile b/drivers/block/Makefile >>> index 41217c1..44baee3 100644 >>> --- a/drivers/block/Makefile >>> +++ b/drivers/block/Makefile >>> @@ -5,12 +5,16 @@ >>> # SPDX-License-Identifier: GPL-2.0+ >>> # >>> >>> -obj-$(CONFIG_BLK) += blk-uclass.o >>> +obj-$(CONFIG_$(SPL_)BLK) += blk-uclass.o >>> >>> ifndef CONFIG_BLK >>> obj-y += blk_legacy.o >>> endif >>> >>> +ifdef SPL_ >>> +obj-y += blk_legacy.o >>> +endif >> >> >> I am facing a same problem with DM_ETH as well. >> How about something like: >> >> ifeq ($(CONFIG_$(SPL_)DM)$(CONFIG_BLK),yy) >> obj-y += blk_uclass.o >> else >> obj-y += blk_legacy.o >> endif >> >> >> Is this an acceptable solution? > > No, I think this is really highlighting that we need to figure out a > solution to using DM inside of SPL on these classes of devices. I think > the last time I started to think out loud about how to solve this my > suggestion was to make a "dummy" board dts file that is correct enough > for SPL needs and that we can bring up full U-Boot on. Off the top of > my head, the differences between BBB/BBW/GP-EVM/EVM-SK/BBG are not > things we would see inside of SPL. In a similar manner we should be > able to get am43xx going, and dra7xx/am57xx going. > >
We don't really need DT support in SPL for using DM, we could statically instantiate device drivers using a board file type system, platform_add_device(device_data) etc.. My biggest objection is in SPL bloat. What do we get by adding DM to SPL? Code re-use is nice, but SPL had hard needs in speed and size that will continue to be eroded by these changes. Perhaps it is time to re-consider adding separate defconfigs/Makefiles for SPL? > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
