SDHCI enumeration order, dynamic mmcblkN IDs, and devicetree

[Stephen Warren]

Grant Likely wrote at Saturday, April 30, 2011 1:41 AM:
> On Fri, Apr 29, 2011 at 09:34:37PM -0700, Stephen Warren wrote:
> > The SDHCI driver assigns dynamic device numbers (mmcblk0/1/...) to
> > devices based on when they get probed, which IDs are free at that time,
> > etc. Many boards have e.g. 1 fixed MMC soldered onto the board, and 1
> > SD slot. There may or may not be a card in the SD slot at probe time,
> > which can then cause the numbering of the fixed MMC to differ.
> >
> > Developers (even boot scripts) want to create simple hard-coded command-
> > lines based on static device IDs, e.g. root=/dev/mmcblk1p3.
> >
> > To reconcile these two somewhat conflicting requirements, the order in
> > which the SDHCI controllers are passed to platform_add_devices has been
> > varied, so that all soldered-down storage is registered first (which
> > synchronously probes the device and assigns the block device ID, which
> > is therefore pseudo-static), followed by socketed storage, which then
> > get a dynamic ID. When there is only 1 socketed controller, this dynamic
> > ID ends up being pseudo-static too.
> >
> > The Tegra board files have been doing this for a little while, and the
> > changes to do so were inspired by similar changes to some (IIRC) OMAP
> > board files.
> >
> > Now to the devicetree specific issue:
> >
> > In the model where the board file registers all the platform devices,
> > which then get matched to OF DT nodes, there is only a single board file,
> > and hence only a single order of registration of SDHCI controllers. The
> > order required to achieve pseudo-static numbering may not be the same
> > for all boards; it depends on which SDHCI controllers are used for which
> > purpose. Hence, this workaround essentially doesn't always work anymore.
> >
> > Is there a way in DT to influence the platform device probe order? If not,
> > should there be? Or, are there other ways to work around this? (root=UUID
> > would work, but it's a pain for me to type and set up if I'm constantly
> > rebuilding filesystem images)
> >
> > Thanks for any hints!
> 
> Anytime you need to assign global or user visible names, the best way
> to do it is to create properties in the /aliases node in the form:
> 
> aliases {
> 	mmc0 = &first-sdhci-label;
> 	mmc1 = &second-
> };
> 
> Then the driver has a canonical place to look to determine whether or
> not a name has already been assigned to a device; regardless of
> whether or not the device is registered yet.

I believe that's simply going to define names for the SDHCI controllers
themselves (or allow the controllers to define their own names).

The issue is that the SDHCI block device names and SDHCI controller
names are in a different name-space; using the aliases node to define
the desired names for the controllers isn't going to affect the names
of the block devices that the controllers expose.

That is, unless having an aliases node itself alters the probe order for
the SDHCI controllers, but I doubt that's the case?

> There isn't much in the way of support code for parsing the aliases
> node yet, but that is definitely the approach I would take.  You'll
> also need to make sure the implemented solution is applicable across
> all mmc controller drivers; not just tegra specific.  The details are
> probably fiddly to work out.

I think any solution for Tegra would be generally applicable; it'd be
implemented for the "sdhc-pltfm" device, which is shared between Tegra
and a variety of other SoCs, and the mechanism (DT nodes, the way they
are handled by the SDHCI drivers) should be portable to any other
SDHCI driver as needed.

-- 
nvpublic