[U-Boot] [RFC PATCH] mmc: omap_hsmmc: convert to use dm block devies

Tom Rini trini at konsulko.com
Fri Feb 3 17:23:07 UTC 2017


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.strashko at 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.

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


More information about the U-Boot mailing list