SDHCI enumeration order, dynamic mmcblkN IDs, and devicetree

[Grant Likely]

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.

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.

g.


> 
> -- 
> nvpublic
>