[U-Boot] [PATCH v3 9/9] arm: dts: sunxi: Enumerate MMC2 as MMC1

[Chen-Yu Tsai]

On Mon, Jan 21, 2019 at 7:07 PM Jagan Teki <jagan at amarulasolutions.com> wrote:
>
> On Mon, Jan 21, 2019 at 4:12 PM Chen-Yu Tsai <wens at csie.org> wrote:
> >
> > On Mon, Jan 21, 2019 at 6:32 PM Jagan Teki <jagan at amarulasolutions.com> wrote:
> > >
> > > Environment and fastboot MMC devices are configured based number
> > > of mmc slots defined on particular board in sunxi platform.
> > >
> > > If number of slots are not more than 1, it assigns 0 which usually mmc
> > > device on SD slot. With DM_MMC it is detected as 0 since mmc0 node always
> > > be an mmc device.
> > >
> > > If number of slots are more than 1, it assigns 1 which assumes 0 is mmc
> > > device and 1 is emmc device. But with DM_MMC there is chance of detecting
> > > emmc as device 2 since mmc1 is SDIO as per devicetree definition.
> > >
> > > So override mmc2 to mmc1 in sunxi dtsi, this will eventually detect mmc2
> > > as mmc 1 device even if the board dts has mmc0, mmc1, mmc2.
> > >
> > > Some platforms like A20 has mmc0...mmc3, but there is no usecases now for
> > > enabling all mmc controllers in any of A20 board dts files.
> > >
> > > Signed-off-by: Jagan Teki <jagan at amarulasolutions.com>
> > > ---
> > >  arch/arm/dts/sunxi-u-boot.dtsi | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> > > index 8a9f2a6417..fdd4c80aa4 100644
> > > --- a/arch/arm/dts/sunxi-u-boot.dtsi
> > > +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> > > @@ -1,6 +1,10 @@
> > >  #include <config.h>
> > >
> > >  / {
> > > +       aliases {
> > > +               mmc1 = &mmc2;
> > > +       };
> > > +
> > >         binman {
> > >                 filename = "u-boot-sunxi-with-spl.bin";
> > >                 pad-byte = <0xff>;
> > > --
> > > 2.18.0.321.gffc6fa0e3
> > >
> >
> > Slightly curious. What happens when mmc1 (the real mmc1) is enabled
> > and probes before mmc2 does? Does it take mmc1? What happens then
> > when mmc2 probes and wants mmc1?
>
> Existing sunxi code has MMC_SUNXI_SLOT_EXTRA if the board has second
> MMC device, like eMMC which make default env or fastboot device as 1.
> But with DT definitions eMMC can be probed as mmc2 which can fail to
> get env and fastboot setups.
>
> This override mmc2 to as mmc1 can satisfy the existing code
> identification. I did many code changes to get rid of DT changes but
> it became hard to get via those[1], patch 27 to 31

So it looks like aliases take precedence over auto-numbering, even
if an auto-numbered device is already probed. See

   https://elixir.bootlin.com/u-boot/latest/source/drivers/block/blk-uclass.c#L544

That was the bit of detail that I was asking about. My question was
what happens to the original mmc1 when mmc2 probes/binds with the mmc1
alias. So the result should be that mmc0 is still mmc0, mmc2 becomes
mmc1, and mmc1 becomes mmc2. It would've been nice to see it in the
commit log. It would explain why and how it works, and more importantly,
why it doesn't screw up the system.

> >
> > Also, on the A31, we use mmc3 instead of mmc2 for eMMC. Only mmc3
> > supports DDR transfer modes.
>
> Yes, but as per current usage no board is using all together, if some
> board is using then, it's their duty to enable the same via defconfig
> in future.

I see. Looks like we got lucky.

I realize now that everything was explained in the commit log. However
it lacks a bit of underlying knowledge or context, as I mentioned above.
IMO these details are important, as they are basically your assumptions
when doing the changes.

ChenYu