[U-Boot] [PATCH v4 0/9] mmc: sunxi: Enable DM_MMC

[Andre Przywara <andre.przywara@arm.com>]

On Wed, 30 Jan 2019 18:20:31 +0530
Jagan Teki <jagan@amarulasolutions.com> wrote:

> On Wed, Jan 30, 2019 at 5:17 PM Andre Przywara
> <andre.przywara@arm.com> wrote:
> >
> > On Wed, 30 Jan 2019 11:16:07 +0100
> > Tomas Novotny <tomas@novotny.cz> wrote:
> >
> > Hi,
> >  
> > > On Tue, 29 Jan 2019 15:54:07 +0000, Andre Przywara
> > > <andre.przywara@arm.com> wrote:  
> > > > This series gathers all remaining patches we need to enable
> > > > DM_MMC for Allwinner boards. It relies on the clock gates
> > > > framework already merged, and adds the respective gates and
> > > > resets for each SoC. It then teaches the sunxi MMC driver to
> > > > use the clock framework for those reset and gates clocks. The
> > > > "mod clock", responsible for setting the actual interface
> > > > speed, is still handled in the MMC driver, as the DM_CLK part
> > > > of that is not ready yet (and is not trivial). This allows to
> > > > turn on DM_MMC, and gets rid of the doomsday warning message
> > > > every Allwinner board was blessed with for a while.
> > > >
> > > > This series is available at:
> > > > https://github.com/apritzel/u-boot/commits/sunxi-dm-gates  
> > >
> > > I've briefly tested that branch on A83t mainlined tablet (TBS
> > > A711). I was able to boot from SD card and eMMC.
> > >
> > > Just noticed that message:
> > > MMC:   Device 'mmc at 1c11000': seq 1 is in use by 'mmc at 1c10000'
> > > mmc at 1c0f000: 0, mmc at 1c10000: 2, mmc at 1c11000: 1
> > > I guess that this is the mmc1/2 renaming stuff?  
> >
> > I think so. So is this just a warning, and it continues anyway and
> > works?
> >
> > TBH, I don't like this patch 9/9 very much, I actually believe
> > relying on this numbering scheme in /aliases is something odd and
> > fragile. Especially since Linux (and other OSes) seem to get away
> > without it.
> >
> > For MMC, can't we just enumerate them dynamically? AFAIU the MMC
> > driver would not probe a block device successfully on an SDIO
> > device, would it?
> >
> > But for the sake of having something working, I am fine with the
> > patch, at least on a for-now basis.  
> 
> It's not a simple think that 9/9 fix is for,It's something big like
> w/o that we can't get the default env and fastboot devices because we
> always assign mmc1 for these purposes and indeed mmc1 is SDIO for DT
> enumeration.

Yeah, but why is it enumerating mmc1 in the first place? It doesn't
seem to be usable? The MMC layer should know that there is no block
device behind this SDIO thing, so it shouldn't even bother with
creating a device for it. Certainly Linux works this way.

I understand that it fixes the issue, but it's some sort of hack,
especially as it's applied to all DTs.

Cheers,
Andre.