SDHCI enumeration order, dynamic mmcblkN IDs, and devicetree

[Stephen Warren]

Stephen Warren wrote at Monday, May 02, 2011 10:55 AM:
> 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).

Grant, sorry if I missed it, but I didn't see any reponse to this; does
devicetree provide a mechanism to alter the actual device enumeration
order? As I mentioned, I assume the aliases node has no effect on that.

Thanks.

> 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