[U-Boot] [PATCH 10/14] dm: mmc: sunxi: Add support for driver model

[Maxime Ripard <maxime.ripard@free-electrons.com>]

On Wed, Jul 05, 2017 at 04:57:40PM +0200, Maxime Ripard wrote:
> On Tue, Jul 04, 2017 at 01:33:25PM -0600, Simon Glass wrote:
> > Hi Maxime,
> > 
> > On 21 June 2017 at 01:31, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> > > Hi Simon,
> > >
> > > On Mon, Jun 19, 2017 at 11:11:27AM -0600, Simon Glass wrote:
> > >> Add a driver-model version of this driver which mostly uses the existing
> > >> code. The old code can be removed once all boards are switched over.
> > >>
> > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> > > I'm not sure if you tested that, but we have some code that switches
> > > the MMC indices when using both an eMMC and an external MMC.
> > >
> > > http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c#l494
> > >
> > > This predates my time, but it seems that it was done to have a
> > > consistent boot MMC device ID.
> > >
> > > I'm not really sure we can get rid of it (even if it creates some
> > > issues of it's own), but what would be the impact of a switch to the
> > > device model on that logic?
> > 
> > That is a pretty terrible hack.
> 
> Yes, I know. This is especially bad when used together with other
> tools that rely on one MMC index for example (such as fastboot).
> 
> I wanted to kill it for quite some time, but I'm a bit reluctant due
> to the possible side effects.
> 
> > I'm not sure whether it will continue to work with DM. It does still
> > use the device number in the block device, so maybe...  Do you have
> > a board would use this?
> 
> I guess I do. I'll give it a try or tonight and let you know.

I just tested. Even with an eMMC (which was the first use case for
that hack), it works, even things that are not mainline yet (fastboot,
etc).

It obviously break the old scripts relying on the mmc index, but I
guess that's ok.

There's one regression though. Our eMMC will always be the second one,
which means that the distro bootargs will always boot on the external
SD first (which is always going to be mmc0).

That's due to the fact that the eMMC controller is the third one, and
is thus probed last. We obviously want something deterministic for
fastboot for example, but booting partitions of the media you started
from make sense I guess. And this is what this hack was trying to
address.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170705/9169712d/attachment.sig>