Devicetree: Initialization order of mmc block devices?

Devicetree: Initialization order of mmc block devices?

[Dirk Behme]

Similar to [1] we have a device which has two mmc block devices 
connected: One external removable and a second internal hard wired one. 
Depending on the availability of the external removable mmc card at boot 
time, the internal hard wired device becomes mmcblk1 (external mmc card 
available == mmcblk0) or mmcblk0 if the external one is not there. This 
order is given by the hardware.

With older, non-DT kernels, we used the hack from [2] to control the 
initialization order and force the internal hard wired device to mmcblk0.

Now, we are switching to a newer, DT based kernel. With a DT based 
kernel this hack doesn't seem to work an more.

Any idea how we could influence the initialization order of the mmc 
block devices using a DT based kernel? Ensuring that the internal, hard 
wired mmc card is always mapped to mmcblk0?

Many thanks and best regards

Dirk

[1] https://bugs.maemo.org/show_bug.cgi?id=2747

[2] https://bugs.maemo.org/show_bug.cgi?id=2747

bigger patch for fremantle kernel which extends also platform data 
structures

https://bugs.maemo.org/attachment.cgi?id=2127

--- kernel-2.6.28-20094803.3/arch/arm/mach-omap2/board-rx51-flash.c 
2010-01-24 23:23:10.000000000 +0100
+++ 
kernel-2.6.28-20094803.3-fanoush/arch/arm/mach-omap2/board-rx51-flash.c 
2010-01-24 22:22:02.000000000 +0100
@@ -59,6 +59,7 @@ static struct platform_device *rx51_flas
  static struct twl4030_hsmmc_info mmc[] __initdata = {
  	{
  		.name		= "external",
+		.mmcblk_devidx	= 1,
  		.mmc		= 1,
  		.wires		= 4,
  		.cover_only	= true,
@@ -69,6 +70,7 @@ static struct twl4030_hsmmc_info mmc[] _
  	},
  	{
  		.name		= "internal",
+		.mmcblk_devidx	= 0,
  		.mmc		= 2,
  		.wires		= 8,
  		.gpio_cd	= -EINVAL,
--- kernel-2.6.28-20094803.3/arch/arm/mach-omap2/mmc-twl4030.c 
2010-01-24 23:23:10.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/arch/arm/mach-omap2/mmc-twl4030.c 
2010-01-24 22:59:35.000000000 +0100
@@ -745,6 +745,7 @@ void __init twl4030_mmc_init(struct twl4
  		else
  			sprintf(twl->name, "mmc%islot%i", c->mmc, 1);
  		mmc->slots[0].name = twl->name;
+		mmc->slots[0].mmcblk_devidx = c->mmcblk_devidx;
  		mmc->nr_slots = 1;
  		mmc->slots[0].wires = c->wires;
  		mmc->slots[0].internal_clock = !c->ext_clock;
--- kernel-2.6.28-20094803.3/arch/arm/mach-omap2/mmc-twl4030.h 
2010-01-24 23:23:10.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/arch/arm/mach-omap2/mmc-twl4030.h 
2010-01-24 22:20:51.000000000 +0100
@@ -19,6 +19,7 @@ struct twl4030_hsmmc_info {
  	int	gpio_cd;	/* or -EINVAL */
  	int	gpio_wp;	/* or -EINVAL */
  	char	*name;		/* or NULL for default */
+	int	mmcblk_devidx;  /* preferred mmcblkX device index */
  };

  #if	defined(CONFIG_TWL4030_CORE) && \
--- kernel-2.6.28-20094803.3/arch/arm/plat-omap/include/mach/mmc.h 
2010-01-24 23:23:10.000000000 +0100
+++ 
kernel-2.6.28-20094803.3-fanoush/arch/arm/plat-omap/include/mach/mmc.h 
2010-01-24 22:53:59.000000000 +0100
@@ -110,6 +110,7 @@ struct omap_mmc_platform_data {
  		int (* get_cover_state)(struct device *dev, int slot);

  		const char *name;
+		int mmcblk_devidx; /* preferred mmcblkX index for this slot */
  		u32 ocr_mask;

  		/* Card detection IRQs */
--- kernel-2.6.28-20094803.3/drivers/mmc/card/block.c	2010-01-24 
23:23:09.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/drivers/mmc/card/block.c	2010-01-24 
22:14:12.000000000 +0100
@@ -479,7 +479,7 @@ static struct mmc_blk_data *mmc_blk_allo
  	struct mmc_blk_data *md;
  	int devidx, ret;

-	devidx = find_first_zero_bit(dev_use, MMC_NUM_MINORS);
+	devidx = find_next_zero_bit(dev_use, MMC_NUM_MINORS, 
card->host->mmcblk_devidx);
  	if (devidx >= MMC_NUM_MINORS)
  		return ERR_PTR(-ENOSPC);
  	__set_bit(devidx, dev_use);
--- kernel-2.6.28-20094803.3/drivers/mmc/host/omap_hsmmc.c	2010-01-24 
23:23:09.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/drivers/mmc/host/omap_hsmmc.c 
2010-01-25 12:27:07.000000000 +0100
@@ -1710,6 +1710,7 @@ static int __init omap_hsmmc_probe(struc
  	mmc->max_seg_size = mmc->max_req_size;

  	mmc->ocr_avail = mmc_slot(host).ocr_mask;
+	mmc->mmcblk_devidx = mmc_slot(host).mmcblk_devidx;
  	mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED;

  	if (mmc_slot(host).wires >= 8)
--- kernel-2.6.28-20094803.3/include/linux/mmc/host.h	2010-01-24 
23:23:10.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/include/linux/mmc/host.h	2010-01-24 
22:12:20.000000000 +0100
@@ -207,7 +207,7 @@ struct mmc_host {
  #endif

  	struct dentry		*debugfs_root;
-
+	unsigned int		mmcblk_devidx; /* preferred mmc block device index 
(mmcblkX) */
  	unsigned long		private[0] ____cacheline_aligned;
  };

Devicetree: Initialization order of mmc block devices?

[Dirk Behme]

Similar to [1] we have a device which has two mmc block devices 
connected: One external removable and a second internal hard wired one. 
Depending on the availability of the external removable mmc card at boot 
time, the internal hard wired device becomes mmcblk1 (external mmc card 
available == mmcblk0) or mmcblk0 if the external one is not there. This 
order is given by the hardware.

With older, non-DT kernels, we used the hack from [2] to control the 
initialization order and force the internal hard wired device to mmcblk0.

Now, we are switching to a newer, DT based kernel. With a DT based 
kernel this hack doesn't seem to work an more.

Any idea how we could influence the initialization order of the mmc 
block devices using a DT based kernel? Ensuring that the internal, hard 
wired mmc card is always mapped to mmcblk0?

Many thanks and best regards

Dirk

[1] https://bugs.maemo.org/show_bug.cgi?id=2747

[2] https://bugs.maemo.org/show_bug.cgi?id=2747

bigger patch for fremantle kernel which extends also platform data 
structures

https://bugs.maemo.org/attachment.cgi?id=2127

--- kernel-2.6.28-20094803.3/arch/arm/mach-omap2/board-rx51-flash.c 
2010-01-24 23:23:10.000000000 +0100
+++ 
kernel-2.6.28-20094803.3-fanoush/arch/arm/mach-omap2/board-rx51-flash.c 
2010-01-24 22:22:02.000000000 +0100
@@ -59,6 +59,7 @@ static struct platform_device *rx51_flas
  static struct twl4030_hsmmc_info mmc[] __initdata = {
  	{
  		.name		= "external",
+		.mmcblk_devidx	= 1,
  		.mmc		= 1,
  		.wires		= 4,
  		.cover_only	= true,
@@ -69,6 +70,7 @@ static struct twl4030_hsmmc_info mmc[] _
  	},
  	{
  		.name		= "internal",
+		.mmcblk_devidx	= 0,
  		.mmc		= 2,
  		.wires		= 8,
  		.gpio_cd	= -EINVAL,
--- kernel-2.6.28-20094803.3/arch/arm/mach-omap2/mmc-twl4030.c 
2010-01-24 23:23:10.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/arch/arm/mach-omap2/mmc-twl4030.c 
2010-01-24 22:59:35.000000000 +0100
@@ -745,6 +745,7 @@ void __init twl4030_mmc_init(struct twl4
  		else
  			sprintf(twl->name, "mmc%islot%i", c->mmc, 1);
  		mmc->slots[0].name = twl->name;
+		mmc->slots[0].mmcblk_devidx = c->mmcblk_devidx;
  		mmc->nr_slots = 1;
  		mmc->slots[0].wires = c->wires;
  		mmc->slots[0].internal_clock = !c->ext_clock;
--- kernel-2.6.28-20094803.3/arch/arm/mach-omap2/mmc-twl4030.h 
2010-01-24 23:23:10.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/arch/arm/mach-omap2/mmc-twl4030.h 
2010-01-24 22:20:51.000000000 +0100
@@ -19,6 +19,7 @@ struct twl4030_hsmmc_info {
  	int	gpio_cd;	/* or -EINVAL */
  	int	gpio_wp;	/* or -EINVAL */
  	char	*name;		/* or NULL for default */
+	int	mmcblk_devidx;  /* preferred mmcblkX device index */
  };

  #if	defined(CONFIG_TWL4030_CORE) && \
--- kernel-2.6.28-20094803.3/arch/arm/plat-omap/include/mach/mmc.h 
2010-01-24 23:23:10.000000000 +0100
+++ 
kernel-2.6.28-20094803.3-fanoush/arch/arm/plat-omap/include/mach/mmc.h 
2010-01-24 22:53:59.000000000 +0100
@@ -110,6 +110,7 @@ struct omap_mmc_platform_data {
  		int (* get_cover_state)(struct device *dev, int slot);

  		const char *name;
+		int mmcblk_devidx; /* preferred mmcblkX index for this slot */
  		u32 ocr_mask;

  		/* Card detection IRQs */
--- kernel-2.6.28-20094803.3/drivers/mmc/card/block.c	2010-01-24 
23:23:09.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/drivers/mmc/card/block.c	2010-01-24 
22:14:12.000000000 +0100
@@ -479,7 +479,7 @@ static struct mmc_blk_data *mmc_blk_allo
  	struct mmc_blk_data *md;
  	int devidx, ret;

-	devidx = find_first_zero_bit(dev_use, MMC_NUM_MINORS);
+	devidx = find_next_zero_bit(dev_use, MMC_NUM_MINORS, 
card->host->mmcblk_devidx);
  	if (devidx >= MMC_NUM_MINORS)
  		return ERR_PTR(-ENOSPC);
  	__set_bit(devidx, dev_use);
--- kernel-2.6.28-20094803.3/drivers/mmc/host/omap_hsmmc.c	2010-01-24 
23:23:09.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/drivers/mmc/host/omap_hsmmc.c 
2010-01-25 12:27:07.000000000 +0100
@@ -1710,6 +1710,7 @@ static int __init omap_hsmmc_probe(struc
  	mmc->max_seg_size = mmc->max_req_size;

  	mmc->ocr_avail = mmc_slot(host).ocr_mask;
+	mmc->mmcblk_devidx = mmc_slot(host).mmcblk_devidx;
  	mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED;

  	if (mmc_slot(host).wires >= 8)
--- kernel-2.6.28-20094803.3/include/linux/mmc/host.h	2010-01-24 
23:23:10.000000000 +0100
+++ kernel-2.6.28-20094803.3-fanoush/include/linux/mmc/host.h	2010-01-24 
22:12:20.000000000 +0100
@@ -207,7 +207,7 @@ struct mmc_host {
  #endif

  	struct dentry		*debugfs_root;
-
+	unsigned int		mmcblk_devidx; /* preferred mmc block device index 
(mmcblkX) */
  	unsigned long		private[0] ____cacheline_aligned;
  };

Re: Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 18 July 2012 11:56, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>
> Similar to [1] we have a device which has two mmc block devices connected:
> One external removable and a second internal hard wired one. Depending on
> the availability of the external removable mmc card at boot time, the
> internal hard wired device becomes mmcblk1 (external mmc card available ==
> mmcblk0) or mmcblk0 if the external one is not there. This order is given by
> the hardware.
>
> With older, non-DT kernels, we used the hack from [2] to control the
> initialization order and force the internal hard wired device to mmcblk0.
>
> Now, we are switching to a newer, DT based kernel. With a DT based kernel
> this hack doesn't seem to work an more.
>
> Any idea how we could influence the initialization order of the mmc block
> devices using a DT based kernel? Ensuring that the internal, hard wired mmc
> card is always mapped to mmcblk0?
>
Doesn't it work by simply by moving the "internal" element before
"external" in the array 'struct twl4030_hsmmc_info mmc[]' ?

Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 18 July 2012 11:56, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>
> Similar to [1] we have a device which has two mmc block devices connected:
> One external removable and a second internal hard wired one. Depending on
> the availability of the external removable mmc card at boot time, the
> internal hard wired device becomes mmcblk1 (external mmc card available ==
> mmcblk0) or mmcblk0 if the external one is not there. This order is given by
> the hardware.
>
> With older, non-DT kernels, we used the hack from [2] to control the
> initialization order and force the internal hard wired device to mmcblk0.
>
> Now, we are switching to a newer, DT based kernel. With a DT based kernel
> this hack doesn't seem to work an more.
>
> Any idea how we could influence the initialization order of the mmc block
> devices using a DT based kernel? Ensuring that the internal, hard wired mmc
> card is always mapped to mmcblk0?
>
Doesn't it work by simply by moving the "internal" element before
"external" in the array 'struct twl4030_hsmmc_info mmc[]' ?

Re: Devicetree: Initialization order of mmc block devices?

[Knut Wohlrab]

On 07/18/2012 09:23 AM, Jassi Brar wrote:
> On 18 July 2012 11:56, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>> Similar to [1] we have a device which has two mmc block devices connected:
>> One external removable and a second internal hard wired one. Depending on
>> the availability of the external removable mmc card at boot time, the
>> internal hard wired device becomes mmcblk1 (external mmc card available ==
>> mmcblk0) or mmcblk0 if the external one is not there. This order is given by
>> the hardware.
>>
>> With older, non-DT kernels, we used the hack from [2] to control the
>> initialization order and force the internal hard wired device to mmcblk0.
>>
>> Now, we are switching to a newer, DT based kernel. With a DT based kernel
>> this hack doesn't seem to work an more.
>>
>> Any idea how we could influence the initialization order of the mmc block
>> devices using a DT based kernel? Ensuring that the internal, hard wired mmc
>> card is always mapped to mmcblk0?
>>
> Doesn't it work by simply by moving the "internal" element before
> "external" in the array 'struct twl4030_hsmmc_info mmc[]' ?

Thanks a lot for quick response. Yes, the order of MMC devices in the 
hardware definition of a board file is a possible solution. But we are 
using a device tree file (*.dts) with this definitions:
...
usdhc@02198000 { /* uSDHC3, eMMC */
     fsl,card-wired;
     status = "okay";
};

usdhc@02190000 { /* uSDHC1, SD card */
     cd-gpios = <&gpio1 4 0>;
     wp-gpios = <&gpio1 2 0>;
     status = "okay";
};
....
The order of the entries doesn't matter. The SDHC controller 1 is probed 
first. If a SD card is inserted at boot time, its "mmcblk0", the 
embedded MMC (eMMC) device "mmcblk1".  This makes it difficult to give 
the kernel the correct device for the eMMC root file system 
("root=/dev/mmcblk?p1 ...").

Is there any solution to define a scan order or a MMC device number/name 
with a device tree?

Thanks a lot and best regards

Knut

Devicetree: Initialization order of mmc block devices?

[Knut Wohlrab]

On 07/18/2012 09:23 AM, Jassi Brar wrote:
> On 18 July 2012 11:56, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>> Similar to [1] we have a device which has two mmc block devices connected:
>> One external removable and a second internal hard wired one. Depending on
>> the availability of the external removable mmc card at boot time, the
>> internal hard wired device becomes mmcblk1 (external mmc card available ==
>> mmcblk0) or mmcblk0 if the external one is not there. This order is given by
>> the hardware.
>>
>> With older, non-DT kernels, we used the hack from [2] to control the
>> initialization order and force the internal hard wired device to mmcblk0.
>>
>> Now, we are switching to a newer, DT based kernel. With a DT based kernel
>> this hack doesn't seem to work an more.
>>
>> Any idea how we could influence the initialization order of the mmc block
>> devices using a DT based kernel? Ensuring that the internal, hard wired mmc
>> card is always mapped to mmcblk0?
>>
> Doesn't it work by simply by moving the "internal" element before
> "external" in the array 'struct twl4030_hsmmc_info mmc[]' ?

Thanks a lot for quick response. Yes, the order of MMC devices in the 
hardware definition of a board file is a possible solution. But we are 
using a device tree file (*.dts) with this definitions:
...
usdhc at 02198000 { /* uSDHC3, eMMC */
     fsl,card-wired;
     status = "okay";
};

usdhc at 02190000 { /* uSDHC1, SD card */
     cd-gpios = <&gpio1 4 0>;
     wp-gpios = <&gpio1 2 0>;
     status = "okay";
};
....
The order of the entries doesn't matter. The SDHC controller 1 is probed 
first. If a SD card is inserted at boot time, its "mmcblk0", the 
embedded MMC (eMMC) device "mmcblk1".  This makes it difficult to give 
the kernel the correct device for the eMMC root file system 
("root=/dev/mmcblk?p1 ...").

Is there any solution to define a scan order or a MMC device number/name 
with a device tree?

Thanks a lot and best regards

Knut

Re: Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:

> If a SD card is inserted at boot time, its "mmcblk0", the embedded
> MMC (eMMC) device "mmcblk1".  This makes it difficult to give the kernel the
> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>
How about  root=UUID=<eMMC-partition>  ?

Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:

> If a SD card is inserted at boot time, its "mmcblk0", the embedded
> MMC (eMMC) device "mmcblk1".  This makes it difficult to give the kernel the
> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>
How about  root=UUID=<eMMC-partition>  ?

Re: Devicetree: Initialization order of mmc block devices?

[Knut Wohlrab]

On 07/18/2012 03:47 PM, Jassi Brar wrote:
> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>
>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>> MMC (eMMC) device "mmcblk1".  This makes it difficult to give the kernel the
>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>
> How about  root=UUID=<eMMC-partition>  ?
Because we are talking about an embedded device, it is very difficult to 
get a UUID of a eMMC partition into kernel command line with U-Boot. 
Handling of UUID is also a big effort at board manufacturing.

Startup speed is very important for us. Searching for UUID on several 
MMC/SD devices will significant slow down the boot process.

This problem can occur on many devices with embedded MMC and removable 
SD, e.g. smart phones. So I think we should find an solution to define 
MMC scan order or device number/name in a device tree.

Thanks and regards

Knut

Devicetree: Initialization order of mmc block devices?

[Knut Wohlrab]

On 07/18/2012 03:47 PM, Jassi Brar wrote:
> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>
>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>> MMC (eMMC) device "mmcblk1".  This makes it difficult to give the kernel the
>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>
> How about  root=UUID=<eMMC-partition>  ?
Because we are talking about an embedded device, it is very difficult to 
get a UUID of a eMMC partition into kernel command line with U-Boot. 
Handling of UUID is also a big effort at board manufacturing.

Startup speed is very important for us. Searching for UUID on several 
MMC/SD devices will significant slow down the boot process.

This problem can occur on many devices with embedded MMC and removable 
SD, e.g. smart phones. So I think we should find an solution to define 
MMC scan order or device number/name in a device tree.

Thanks and regards

Knut

Re: Devicetree: Initialization order of mmc block devices?

[Eric Nelson]

On 07/18/2012 07:11 AM, Knut Wohlrab wrote:
> On 07/18/2012 03:47 PM, Jassi Brar wrote:
>> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>>
>>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>>> MMC (eMMC) device "mmcblk1". This makes it difficult to give the kernel the
>>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>>
>> How about root=UUID=<eMMC-partition> ?
> Because we are talking about an embedded device, it is very difficult to get a
> UUID of a eMMC partition into kernel command line with U-Boot. Handling of UUID
> is also a big effort at board manufacturing.
>
> Startup speed is very important for us. Searching for UUID on several MMC/SD
> devices will significant slow down the boot process.
>
> This problem can occur on many devices with embedded MMC and removable SD, e.g.
> smart phones. So I think we should find an solution to define MMC scan order or
> device number/name in a device tree.
>

Isn't /dev/disk/by-path what you're after?

~$ ls -l /dev/disk/by-path/
lrwxrwxrwx    1 root     root           13 Jan  1 15:22 platform-mmc0:b368 -> 
../../mmcblk0
lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part1 
-> ../../mmcblk0p1
lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part2 
-> ../../mmcblk0p2
lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part3 
-> ../../mmcblk0p3

Devicetree: Initialization order of mmc block devices?

[Eric Nelson]

On 07/18/2012 07:11 AM, Knut Wohlrab wrote:
> On 07/18/2012 03:47 PM, Jassi Brar wrote:
>> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>>
>>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>>> MMC (eMMC) device "mmcblk1". This makes it difficult to give the kernel the
>>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>>
>> How about root=UUID=<eMMC-partition> ?
> Because we are talking about an embedded device, it is very difficult to get a
> UUID of a eMMC partition into kernel command line with U-Boot. Handling of UUID
> is also a big effort at board manufacturing.
>
> Startup speed is very important for us. Searching for UUID on several MMC/SD
> devices will significant slow down the boot process.
>
> This problem can occur on many devices with embedded MMC and removable SD, e.g.
> smart phones. So I think we should find an solution to define MMC scan order or
> device number/name in a device tree.
>

Isn't /dev/disk/by-path what you're after?

~$ ls -l /dev/disk/by-path/
lrwxrwxrwx    1 root     root           13 Jan  1 15:22 platform-mmc0:b368 -> 
../../mmcblk0
lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part1 
-> ../../mmcblk0p1
lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part2 
-> ../../mmcblk0p2
lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part3 
-> ../../mmcblk0p3

Re: Devicetree: Initialization order of mmc block devices?

[Knut Wohlrab]

On 07/18/2012 04:54 PM, Eric Nelson wrote:
> On 07/18/2012 07:11 AM, Knut Wohlrab wrote:
>> On 07/18/2012 03:47 PM, Jassi Brar wrote:
>>> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>>>
>>>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>>>> MMC (eMMC) device "mmcblk1". This makes it difficult to give the kernel the
>>>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>>>
>>> How about root=UUID=<eMMC-partition> ?
>> Because we are talking about an embedded device, it is very difficult to get a
>> UUID of a eMMC partition into kernel command line with U-Boot. Handling of UUID
>> is also a big effort at board manufacturing.
>>
>> Startup speed is very important for us. Searching for UUID on several MMC/SD
>> devices will significant slow down the boot process.
>>
>> This problem can occur on many devices with embedded MMC and removable SD, e.g.
>> smart phones. So I think we should find an solution to define MMC scan order or
>> device number/name in a device tree.
>>
> Isn't /dev/disk/by-path what you're after?
>
> ~$ ls -l /dev/disk/by-path/
> lrwxrwxrwx    1 root     root           13 Jan  1 15:22 platform-mmc0:b368 ->
> ../../mmcblk0
> lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part1
> -> ../../mmcblk0p1
> lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part2
> -> ../../mmcblk0p2
> lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part3
> -> ../../mmcblk0p3
No, because we have to know which will be the name of the root device 
_before_ we start the kernel. In our embedded device we start the kernel 
with a bootloader (U-Boot) and pass the root device with the kernel 
command line parameter "root=/dev/mmcblk0p1". That is not possible if we 
do not know what will be the name of the root device (mmcblk0 or 
mmcblk1) when kernel try to mount it.

Thanks and regards

Knut

Devicetree: Initialization order of mmc block devices?

[Knut Wohlrab]

On 07/18/2012 04:54 PM, Eric Nelson wrote:
> On 07/18/2012 07:11 AM, Knut Wohlrab wrote:
>> On 07/18/2012 03:47 PM, Jassi Brar wrote:
>>> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>>>
>>>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>>>> MMC (eMMC) device "mmcblk1". This makes it difficult to give the kernel the
>>>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>>>
>>> How about root=UUID=<eMMC-partition> ?
>> Because we are talking about an embedded device, it is very difficult to get a
>> UUID of a eMMC partition into kernel command line with U-Boot. Handling of UUID
>> is also a big effort at board manufacturing.
>>
>> Startup speed is very important for us. Searching for UUID on several MMC/SD
>> devices will significant slow down the boot process.
>>
>> This problem can occur on many devices with embedded MMC and removable SD, e.g.
>> smart phones. So I think we should find an solution to define MMC scan order or
>> device number/name in a device tree.
>>
> Isn't /dev/disk/by-path what you're after?
>
> ~$ ls -l /dev/disk/by-path/
> lrwxrwxrwx    1 root     root           13 Jan  1 15:22 platform-mmc0:b368 ->
> ../../mmcblk0
> lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part1
> -> ../../mmcblk0p1
> lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part2
> -> ../../mmcblk0p2
> lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part3
> -> ../../mmcblk0p3
No, because we have to know which will be the name of the root device 
_before_ we start the kernel. In our embedded device we start the kernel 
with a bootloader (U-Boot) and pass the root device with the kernel 
command line parameter "root=/dev/mmcblk0p1". That is not possible if we 
do not know what will be the name of the root device (mmcblk0 or 
mmcblk1) when kernel try to mount it.

Thanks and regards

Knut

Re: Devicetree: Initialization order of mmc block devices?

[Thomas Petazzoni]

Le Wed, 18 Jul 2012 17:16:49 +0200,
Knut Wohlrab <knut.wohlrab@de.bosch.com> a écrit :

> No, because we have to know which will be the name of the root device 
> _before_ we start the kernel. In our embedded device we start the kernel 
> with a bootloader (U-Boot) and pass the root device with the kernel 
> command line parameter "root=/dev/mmcblk0p1". That is not possible if we 
> do not know what will be the name of the root device (mmcblk0 or 
> mmcblk1) when kernel try to mount it.

You can always work around this by having a minimal initramfs inside
your kernel, which contains a basic userspace environment that will
just locate the right location of the real root filesystem, mount it,
and switch to it. But I agree that it's a bit painful to have such a
complexity just to identify which device contains the root filesystem.

I also believe the root=UUID=... thing does not work when root= is
parsed by the kernel, unless you have a GPT partition table or
something like that. With the old-style partition table, the UUIDs are
inside the filesystems, and the kernel does not know about them. At
least that was my understanding of the matter about a year ago when I
looked into this.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Devicetree: Initialization order of mmc block devices?

[Thomas Petazzoni]

Le Wed, 18 Jul 2012 17:16:49 +0200,
Knut Wohlrab <knut.wohlrab@de.bosch.com> a ?crit :

> No, because we have to know which will be the name of the root device 
> _before_ we start the kernel. In our embedded device we start the kernel 
> with a bootloader (U-Boot) and pass the root device with the kernel 
> command line parameter "root=/dev/mmcblk0p1". That is not possible if we 
> do not know what will be the name of the root device (mmcblk0 or 
> mmcblk1) when kernel try to mount it.

You can always work around this by having a minimal initramfs inside
your kernel, which contains a basic userspace environment that will
just locate the right location of the real root filesystem, mount it,
and switch to it. But I agree that it's a bit painful to have such a
complexity just to identify which device contains the root filesystem.

I also believe the root=UUID=... thing does not work when root= is
parsed by the kernel, unless you have a GPT partition table or
something like that. With the old-style partition table, the UUIDs are
inside the filesystems, and the kernel does not know about them. At
least that was my understanding of the matter about a year ago when I
looked into this.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: Devicetree: Initialization order of mmc block devices?

[Arnd Bergmann]

On Wednesday 18 July 2012, Dirk Behme wrote:
> Any idea how we could influence the initialization order of the mmc 
> block devices using a DT based kernel? Ensuring that the internal, hard 
> wired mmc card is always mapped to mmcblk0?

I think the best solution would be to parse the "/aliases" device node
and look for an "mmc0" or "mmc1" property with a phandle to the respective
device. That's how we sort the serial ports. We have the of_alias_get_id()
function to pick out a node from there, so it should be possible to use
that in the mmc core similar to how we use it in the uart drivers.

	Arnd

Devicetree: Initialization order of mmc block devices?

[Arnd Bergmann]

On Wednesday 18 July 2012, Dirk Behme wrote:
> Any idea how we could influence the initialization order of the mmc 
> block devices using a DT based kernel? Ensuring that the internal, hard 
> wired mmc card is always mapped to mmcblk0?

I think the best solution would be to parse the "/aliases" device node
and look for an "mmc0" or "mmc1" property with a phandle to the respective
device. That's how we sort the serial ports. We have the of_alias_get_id()
function to pick out a node from there, so it should be possible to use
that in the mmc core similar to how we use it in the uart drivers.

	Arnd

Re: Devicetree: Initialization order of mmc block devices?

[Matthias Kaehlcke]

El Wed, Jul 18, 2012 at 05:16:49PM +0200 Knut Wohlrab ha dit:

> On 07/18/2012 04:54 PM, Eric Nelson wrote:
> >On 07/18/2012 07:11 AM, Knut Wohlrab wrote:
> >>On 07/18/2012 03:47 PM, Jassi Brar wrote:
> >>>On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
> >>>
> >>>>If a SD card is inserted at boot time, its "mmcblk0", the embedded
> >>>>MMC (eMMC) device "mmcblk1". This makes it difficult to give the kernel the
> >>>>correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
> >>>>
> >>>How about root=UUID=<eMMC-partition> ?
> >>Because we are talking about an embedded device, it is very difficult to get a
> >>UUID of a eMMC partition into kernel command line with U-Boot. Handling of UUID
> >>is also a big effort at board manufacturing.
> >>
> >>Startup speed is very important for us. Searching for UUID on several MMC/SD
> >>devices will significant slow down the boot process.
> >>
> >>This problem can occur on many devices with embedded MMC and removable SD, e.g.
> >>smart phones. So I think we should find an solution to define MMC scan order or
> >>device number/name in a device tree.
> >>
> >Isn't /dev/disk/by-path what you're after?
> >
> >~$ ls -l /dev/disk/by-path/
> >lrwxrwxrwx    1 root     root           13 Jan  1 15:22 platform-mmc0:b368 ->
> >../../mmcblk0
> >lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part1
> >-> ../../mmcblk0p1
> >lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part2
> >-> ../../mmcblk0p2
> >lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part3
> >-> ../../mmcblk0p3
> No, because we have to know which will be the name of the root
> device _before_ we start the kernel. In our embedded device we start
> the kernel with a bootloader (U-Boot) and pass the root device with
> the kernel command line parameter "root=/dev/mmcblk0p1". That is not
> possible if we do not know what will be the name of the root device
> (mmcblk0 or mmcblk1) when kernel try to mount it.

what you can do is let u-boot pass the mmc channel of the boot device,
launch a tiny init from initramfs to perform the resolution to
/dev/mmcblkXpY (for example through /sys/class/mmc_host/...), mount
the real rootfs and exec the real init

best regards

-- 
Matthias Kaehlcke
Embedded Linux Developer
Amsterdam

   Usually when people are sad, they don't do anything. They just cry over
     their condition. But when they get angry, they bring about a change
                              (Malcolm X)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-

Devicetree: Initialization order of mmc block devices?

[Matthias Kaehlcke]

El Wed, Jul 18, 2012 at 05:16:49PM +0200 Knut Wohlrab ha dit:

> On 07/18/2012 04:54 PM, Eric Nelson wrote:
> >On 07/18/2012 07:11 AM, Knut Wohlrab wrote:
> >>On 07/18/2012 03:47 PM, Jassi Brar wrote:
> >>>On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
> >>>
> >>>>If a SD card is inserted at boot time, its "mmcblk0", the embedded
> >>>>MMC (eMMC) device "mmcblk1". This makes it difficult to give the kernel the
> >>>>correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
> >>>>
> >>>How about root=UUID=<eMMC-partition> ?
> >>Because we are talking about an embedded device, it is very difficult to get a
> >>UUID of a eMMC partition into kernel command line with U-Boot. Handling of UUID
> >>is also a big effort at board manufacturing.
> >>
> >>Startup speed is very important for us. Searching for UUID on several MMC/SD
> >>devices will significant slow down the boot process.
> >>
> >>This problem can occur on many devices with embedded MMC and removable SD, e.g.
> >>smart phones. So I think we should find an solution to define MMC scan order or
> >>device number/name in a device tree.
> >>
> >Isn't /dev/disk/by-path what you're after?
> >
> >~$ ls -l /dev/disk/by-path/
> >lrwxrwxrwx    1 root     root           13 Jan  1 15:22 platform-mmc0:b368 ->
> >../../mmcblk0
> >lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part1
> >-> ../../mmcblk0p1
> >lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part2
> >-> ../../mmcblk0p2
> >lrwxrwxrwx    1 root     root           15 Jan  1 15:22 platform-mmc0:b368-part3
> >-> ../../mmcblk0p3
> No, because we have to know which will be the name of the root
> device _before_ we start the kernel. In our embedded device we start
> the kernel with a bootloader (U-Boot) and pass the root device with
> the kernel command line parameter "root=/dev/mmcblk0p1". That is not
> possible if we do not know what will be the name of the root device
> (mmcblk0 or mmcblk1) when kernel try to mount it.

what you can do is let u-boot pass the mmc channel of the boot device,
launch a tiny init from initramfs to perform the resolution to
/dev/mmcblkXpY (for example through /sys/class/mmc_host/...), mount
the real rootfs and exec the real init

best regards

-- 
Matthias Kaehlcke
Embedded Linux Developer
Amsterdam

   Usually when people are sad, they don't do anything. They just cry over
     their condition. But when they get angry, they bring about a change
                              (Malcolm X)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-

Re: Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 18 July 2012 19:41, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
> On 07/18/2012 03:47 PM, Jassi Brar wrote:
>>
>> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>>
>>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>>> MMC (eMMC) device "mmcblk1".  This makes it difficult to give the kernel
>>> the
>>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>>
>> How about  root=UUID=<eMMC-partition>  ?
>
> Because we are talking about an embedded device, it is very difficult to get
> a UUID of a eMMC partition into kernel command line with U-Boot. Handling of
> UUID is also a big effort at board manufacturing.
>
I don't realize how bad is it if a common UUID is used on each cloned
eMMC(non-removable) of every instance of a device. But of course only
you know what's best for your product.

>
> This problem can occur on many devices with embedded MMC and removable SD,
> e.g. smart phones. So I think we should find an solution to define MMC scan
> order or device number/name in a device tree.
>
I assume your issue is that due to async nature of mmc scanning, the
eMMC is detected later than external card, despite being the probe for
eMMC's slot initiated first ?
If so, we can do by simply associating 'N' of 'mmcblkN' with the slot
index i.e, mmc_host.index (instead of mmc_blk_data.name_idx). Which is
always in the order of probe calling. And we don't need to modify, or
expect more of, DT for that. Though I suspect there must be some
serious reason why it's not already done that way.

Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 18 July 2012 19:41, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
> On 07/18/2012 03:47 PM, Jassi Brar wrote:
>>
>> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>>
>>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>>> MMC (eMMC) device "mmcblk1".  This makes it difficult to give the kernel
>>> the
>>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>>
>> How about  root=UUID=<eMMC-partition>  ?
>
> Because we are talking about an embedded device, it is very difficult to get
> a UUID of a eMMC partition into kernel command line with U-Boot. Handling of
> UUID is also a big effort at board manufacturing.
>
I don't realize how bad is it if a common UUID is used on each cloned
eMMC(non-removable) of every instance of a device. But of course only
you know what's best for your product.

>
> This problem can occur on many devices with embedded MMC and removable SD,
> e.g. smart phones. So I think we should find an solution to define MMC scan
> order or device number/name in a device tree.
>
I assume your issue is that due to async nature of mmc scanning, the
eMMC is detected later than external card, despite being the probe for
eMMC's slot initiated first ?
If so, we can do by simply associating 'N' of 'mmcblkN' with the slot
index i.e, mmc_host.index (instead of mmc_blk_data.name_idx). Which is
always in the order of probe calling. And we don't need to modify, or
expect more of, DT for that. Though I suspect there must be some
serious reason why it's not already done that way.

Re: Devicetree: Initialization order of mmc block devices?

[Dirk Behme]

On 19.07.2012 22:45, Jassi Brar wrote:
> On 18 July 2012 19:41, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>> On 07/18/2012 03:47 PM, Jassi Brar wrote:
>>> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>>>
>>>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>>>> MMC (eMMC) device "mmcblk1".  This makes it difficult to give the kernel
>>>> the
>>>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>>>
>>> How about  root=UUID=<eMMC-partition>  ?
>> Because we are talking about an embedded device, it is very difficult to get
>> a UUID of a eMMC partition into kernel command line with U-Boot. Handling of
>> UUID is also a big effort at board manufacturing.
>>
> I don't realize how bad is it if a common UUID is used on each cloned
> eMMC(non-removable) of every instance of a device. But of course only
> you know what's best for your product.
> 
>> This problem can occur on many devices with embedded MMC and removable SD,
>> e.g. smart phones. So I think we should find an solution to define MMC scan
>> order or device number/name in a device tree.
>>
> I assume your issue is that due to async nature of mmc scanning, the
> eMMC is detected later than external card, despite being the probe for
> eMMC's slot initiated first ?
> If so, we can do by simply associating 'N' of 'mmcblkN' with the slot
> index i.e, mmc_host.index (instead of mmc_blk_data.name_idx). Which is
> always in the order of probe calling. And we don't need to modify, or
> expect more of, DT for that.

Do you mean something like

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1536,7 +1536,7 @@ static struct mmc_blk_data 
*mmc_blk_alloc_req(struct mmc_card *card,
          */

         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
-                "mmcblk%d%s", md->name_idx, subname ? subname : "");
+                "mmcblk%d%s", card->host->index, subname ? subname : "");

         blk_queue_logical_block_size(md->queue.queue, 512);
         set_capacity(md->disk, size);

?

A first quick test looks promising. We will go on testing this.

> Though I suspect there must be some
> serious reason why it's not already done that way.

Anybody with an idea? Any serious reason?

Many thanks and best regards

Dirk

Devicetree: Initialization order of mmc block devices?

[Dirk Behme]

On 19.07.2012 22:45, Jassi Brar wrote:
> On 18 July 2012 19:41, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>> On 07/18/2012 03:47 PM, Jassi Brar wrote:
>>> On 18 July 2012 15:19, Knut Wohlrab <knut.wohlrab@de.bosch.com> wrote:
>>>
>>>> If a SD card is inserted at boot time, its "mmcblk0", the embedded
>>>> MMC (eMMC) device "mmcblk1".  This makes it difficult to give the kernel
>>>> the
>>>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ...").
>>>>
>>> How about  root=UUID=<eMMC-partition>  ?
>> Because we are talking about an embedded device, it is very difficult to get
>> a UUID of a eMMC partition into kernel command line with U-Boot. Handling of
>> UUID is also a big effort at board manufacturing.
>>
> I don't realize how bad is it if a common UUID is used on each cloned
> eMMC(non-removable) of every instance of a device. But of course only
> you know what's best for your product.
> 
>> This problem can occur on many devices with embedded MMC and removable SD,
>> e.g. smart phones. So I think we should find an solution to define MMC scan
>> order or device number/name in a device tree.
>>
> I assume your issue is that due to async nature of mmc scanning, the
> eMMC is detected later than external card, despite being the probe for
> eMMC's slot initiated first ?
> If so, we can do by simply associating 'N' of 'mmcblkN' with the slot
> index i.e, mmc_host.index (instead of mmc_blk_data.name_idx). Which is
> always in the order of probe calling. And we don't need to modify, or
> expect more of, DT for that.

Do you mean something like

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1536,7 +1536,7 @@ static struct mmc_blk_data 
*mmc_blk_alloc_req(struct mmc_card *card,
          */

         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
-                "mmcblk%d%s", md->name_idx, subname ? subname : "");
+                "mmcblk%d%s", card->host->index, subname ? subname : "");

         blk_queue_logical_block_size(md->queue.queue, 512);
         set_capacity(md->disk, size);

?

A first quick test looks promising. We will go on testing this.

> Though I suspect there must be some
> serious reason why it's not already done that way.

Anybody with an idea? Any serious reason?

Many thanks and best regards

Dirk

Re: Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 20 July 2012 17:00, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> On 19.07.2012 22:45, Jassi Brar wrote:

>>> This problem can occur on many devices with embedded MMC and removable
>>> SD,
>>> e.g. smart phones. So I think we should find an solution to define MMC
>>> scan
>>> order or device number/name in a device tree.
>>>
>> I assume your issue is that due to async nature of mmc scanning, the
>> eMMC is detected later than external card, despite being the probe for
>> eMMC's slot initiated first ?
>> If so, we can do by simply associating 'N' of 'mmcblkN' with the slot
>> index i.e, mmc_host.index (instead of mmc_blk_data.name_idx). Which is
>> always in the order of probe calling. And we don't need to modify, or
>> expect more of, DT for that.
>
>
> Do you mean something like
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -1536,7 +1536,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
> mmc_card *card,
>          */
>
>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> -                "mmcblk%d%s", md->name_idx, subname ? subname : "");
> +                "mmcblk%d%s", card->host->index, subname ? subname : "");
>
>         blk_queue_logical_block_size(md->queue.queue, 512);
>         set_capacity(md->disk, size);
>
> ?
>
Exactly!
It seems too trivial and default for the author to have missed it, so
I suspect I am overlooking something yet again. I would dig email
archives to know more about that naming convention before dare submit
a patch :)

Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 20 July 2012 17:00, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> On 19.07.2012 22:45, Jassi Brar wrote:

>>> This problem can occur on many devices with embedded MMC and removable
>>> SD,
>>> e.g. smart phones. So I think we should find an solution to define MMC
>>> scan
>>> order or device number/name in a device tree.
>>>
>> I assume your issue is that due to async nature of mmc scanning, the
>> eMMC is detected later than external card, despite being the probe for
>> eMMC's slot initiated first ?
>> If so, we can do by simply associating 'N' of 'mmcblkN' with the slot
>> index i.e, mmc_host.index (instead of mmc_blk_data.name_idx). Which is
>> always in the order of probe calling. And we don't need to modify, or
>> expect more of, DT for that.
>
>
> Do you mean something like
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -1536,7 +1536,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
> mmc_card *card,
>          */
>
>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> -                "mmcblk%d%s", md->name_idx, subname ? subname : "");
> +                "mmcblk%d%s", card->host->index, subname ? subname : "");
>
>         blk_queue_logical_block_size(md->queue.queue, 512);
>         set_capacity(md->disk, size);
>
> ?
>
Exactly!
It seems too trivial and default for the author to have missed it, so
I suspect I am overlooking something yet again. I would dig email
archives to know more about that naming convention before dare submit
a patch :)

Re: Devicetree: Initialization order of mmc block devices?

[Dirk Behme]

On 19.07.2012 15:13, Arnd Bergmann wrote:
> On Wednesday 18 July 2012, Dirk Behme wrote:
>> Any idea how we could influence the initialization order of the mmc 
>> block devices using a DT based kernel? Ensuring that the internal, hard 
>> wired mmc card is always mapped to mmcblk0?
> 
> I think the best solution would be to parse the "/aliases" device node
> and look for an "mmc0" or "mmc1" property with a phandle to the respective
> device. That's how we sort the serial ports. We have the of_alias_get_id()
> function to pick out a node from there, so it should be possible to use
> that in the mmc core similar to how we use it in the uart drivers.

Looking at the serial example you mentioned and trying to adapt that for 
mmcblkX I tried something like below [1] on a Freescale i.MX6 board and 
it seems to work :) Is this what you had in mind?

While I think the DT/of_alias_get_id() part looks ok (?), the way of 
passing the retrieved value from the driver sdhci-esdhc-imx.c to the 
block.c is quite hackish. I took it from the examples how this was 
hacked in the past.

Is there any better way of passing the information read in the driver by 
of_alias_get_id() to block.c? With the value read by of_alias_get_id() 
we somehow have to set name_idx in block.c.

Best regards

Dirk

[1]

Just fyi: From hardware point of view, usdhc1 connects the removable SD 
card, while usdhc3 attaches the non-removable eMMC. With the alias, 
independent if the SD card is there or not, the eMMC becomes always 
mmcblk1. And this is what we like to achieve here.

---
  arch/arm/boot/dts/imx6q-sabrelite.dts         |    5 +++++
  arch/arm/plat-mxc/include/mach/esdhc.h |    1 +
  drivers/mmc/card/block.c               |    6 ++++--
  drivers/mmc/host/sdhci-esdhc-imx.c     |   14 ++++++++++++++
  include/linux/mmc/host.h               |    3 +++
  5 files changed, 27 insertions(+), 2 deletions(-)

Index: a/arch/arm/boot/dts/imx6q-sabrelite.dts
===================================================================
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -18,6 +18,11 @@
  	model = "Freescale i.MX6 Quad sabrelite Sample Board";
  	compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";

+	aliases {
+		mmcblk0 = &usdhc1;
+		mmcblk1 = &usdhc3;
+	};
+
  	memory {
  		reg = <0x10000000 0x40000000>;
  	};
  	Index: freescale-linux-2.6-imx.git/drivers/mmc/host/sdhci-esdhc-imx.c
===================================================================
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -447,10 +447,21 @@ sdhci_esdhc_imx_probe_dt(struct platform
  			 struct esdhc_platform_data *boarddata)
  {
  	struct device_node *np = pdev->dev.of_node;
+	int ret;

  	if (!np)
  		return -ENODEV;

+	ret = of_alias_get_id(np, "mmcblk");
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
+		return -ENODEV;
+	}
+
+	boarddata->devidx = ret;
+
  	if (of_get_property(np, "fsl,card-wired", NULL))
  		boarddata->cd_type = ESDHC_CD_PERMANENT;

@@ -581,6 +592,9 @@ static int __devinit sdhci_esdhc_imx_pro
  					host->mmc->parent->platform_data);
  	}

+	/* copy mmc block device index */
+	host->mmc->devidx = boarddata->devidx;
+
  	/* write_protect */
  	if (boarddata->wp_type == ESDHC_WP_GPIO) {
  		err = gpio_request_one(boarddata->wp_gpio, GPIOF_IN, "ESDHC_WP");
Index: a/arch/arm/plat-mxc/include/mach/esdhc.h
===================================================================
--- a/arch/arm/plat-mxc/include/mach/esdhc.h
+++ bt/arch/arm/plat-mxc/include/mach/esdhc.h
@@ -41,5 +41,6 @@ struct esdhc_platform_data {
  	enum wp_types wp_type;
  	enum cd_types cd_type;
  	int vdd_180;
+	unsigned int devidx;
  };
  #endif /* __ASM_ARCH_IMX_ESDHC_H */
Index: freescale-linux-2.6-imx.git/drivers/mmc/card/block.c
===================================================================
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1466,7 +1466,8 @@ static struct mmc_blk_data *mmc_blk_allo
  	struct mmc_blk_data *md;
  	int devidx, ret;

-	devidx = find_first_zero_bit(dev_use, max_devices);
+	devidx = find_next_zero_bit(dev_use, max_devices,
+			card->host->devidx);
  	if (devidx >= max_devices)
  		return ERR_PTR(-ENOSPC);
  	__set_bit(devidx, dev_use);
@@ -1484,7 +1485,8 @@ static struct mmc_blk_data *mmc_blk_allo
  	 * index anymore so we keep track of a name index.
  	 */
  	if (!subname) {
-		md->name_idx = find_first_zero_bit(name_use, max_devices);
+		md->name_idx = find_next_zero_bit(name_use, max_devices,
+				card->host->devidx);
  		__set_bit(md->name_idx, name_use);
  	} else
  		md->name_idx = ((struct mmc_blk_data *)
Index: a/include/linux/mmc/host.h
===================================================================
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -326,6 +326,9 @@ struct mmc_host {

  	unsigned int		actual_clock;	/* Actual HC clock rate */

+	/* preferred mmc block device index (mmcblkX) */
+	unsigned int		devidx;
+
  	unsigned long		private[0] ____cacheline_aligned;
  };

Devicetree: Initialization order of mmc block devices?

[Dirk Behme]

On 19.07.2012 15:13, Arnd Bergmann wrote:
> On Wednesday 18 July 2012, Dirk Behme wrote:
>> Any idea how we could influence the initialization order of the mmc 
>> block devices using a DT based kernel? Ensuring that the internal, hard 
>> wired mmc card is always mapped to mmcblk0?
> 
> I think the best solution would be to parse the "/aliases" device node
> and look for an "mmc0" or "mmc1" property with a phandle to the respective
> device. That's how we sort the serial ports. We have the of_alias_get_id()
> function to pick out a node from there, so it should be possible to use
> that in the mmc core similar to how we use it in the uart drivers.

Looking at the serial example you mentioned and trying to adapt that for 
mmcblkX I tried something like below [1] on a Freescale i.MX6 board and 
it seems to work :) Is this what you had in mind?

While I think the DT/of_alias_get_id() part looks ok (?), the way of 
passing the retrieved value from the driver sdhci-esdhc-imx.c to the 
block.c is quite hackish. I took it from the examples how this was 
hacked in the past.

Is there any better way of passing the information read in the driver by 
of_alias_get_id() to block.c? With the value read by of_alias_get_id() 
we somehow have to set name_idx in block.c.

Best regards

Dirk

[1]

Just fyi: From hardware point of view, usdhc1 connects the removable SD 
card, while usdhc3 attaches the non-removable eMMC. With the alias, 
independent if the SD card is there or not, the eMMC becomes always 
mmcblk1. And this is what we like to achieve here.

---
  arch/arm/boot/dts/imx6q-sabrelite.dts         |    5 +++++
  arch/arm/plat-mxc/include/mach/esdhc.h |    1 +
  drivers/mmc/card/block.c               |    6 ++++--
  drivers/mmc/host/sdhci-esdhc-imx.c     |   14 ++++++++++++++
  include/linux/mmc/host.h               |    3 +++
  5 files changed, 27 insertions(+), 2 deletions(-)

Index: a/arch/arm/boot/dts/imx6q-sabrelite.dts
===================================================================
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -18,6 +18,11 @@
  	model = "Freescale i.MX6 Quad sabrelite Sample Board";
  	compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";

+	aliases {
+		mmcblk0 = &usdhc1;
+		mmcblk1 = &usdhc3;
+	};
+
  	memory {
  		reg = <0x10000000 0x40000000>;
  	};
  	Index: freescale-linux-2.6-imx.git/drivers/mmc/host/sdhci-esdhc-imx.c
===================================================================
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -447,10 +447,21 @@ sdhci_esdhc_imx_probe_dt(struct platform
  			 struct esdhc_platform_data *boarddata)
  {
  	struct device_node *np = pdev->dev.of_node;
+	int ret;

  	if (!np)
  		return -ENODEV;

+	ret = of_alias_get_id(np, "mmcblk");
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
+		return -ENODEV;
+	}
+
+	boarddata->devidx = ret;
+
  	if (of_get_property(np, "fsl,card-wired", NULL))
  		boarddata->cd_type = ESDHC_CD_PERMANENT;

@@ -581,6 +592,9 @@ static int __devinit sdhci_esdhc_imx_pro
  					host->mmc->parent->platform_data);
  	}

+	/* copy mmc block device index */
+	host->mmc->devidx = boarddata->devidx;
+
  	/* write_protect */
  	if (boarddata->wp_type == ESDHC_WP_GPIO) {
  		err = gpio_request_one(boarddata->wp_gpio, GPIOF_IN, "ESDHC_WP");
Index: a/arch/arm/plat-mxc/include/mach/esdhc.h
===================================================================
--- a/arch/arm/plat-mxc/include/mach/esdhc.h
+++ bt/arch/arm/plat-mxc/include/mach/esdhc.h
@@ -41,5 +41,6 @@ struct esdhc_platform_data {
  	enum wp_types wp_type;
  	enum cd_types cd_type;
  	int vdd_180;
+	unsigned int devidx;
  };
  #endif /* __ASM_ARCH_IMX_ESDHC_H */
Index: freescale-linux-2.6-imx.git/drivers/mmc/card/block.c
===================================================================
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1466,7 +1466,8 @@ static struct mmc_blk_data *mmc_blk_allo
  	struct mmc_blk_data *md;
  	int devidx, ret;

-	devidx = find_first_zero_bit(dev_use, max_devices);
+	devidx = find_next_zero_bit(dev_use, max_devices,
+			card->host->devidx);
  	if (devidx >= max_devices)
  		return ERR_PTR(-ENOSPC);
  	__set_bit(devidx, dev_use);
@@ -1484,7 +1485,8 @@ static struct mmc_blk_data *mmc_blk_allo
  	 * index anymore so we keep track of a name index.
  	 */
  	if (!subname) {
-		md->name_idx = find_first_zero_bit(name_use, max_devices);
+		md->name_idx = find_next_zero_bit(name_use, max_devices,
+				card->host->devidx);
  		__set_bit(md->name_idx, name_use);
  	} else
  		md->name_idx = ((struct mmc_blk_data *)
Index: a/include/linux/mmc/host.h
===================================================================
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -326,6 +326,9 @@ struct mmc_host {

  	unsigned int		actual_clock;	/* Actual HC clock rate */

+	/* preferred mmc block device index (mmcblkX) */
+	unsigned int		devidx;
+
  	unsigned long		private[0] ____cacheline_aligned;
  };

Re: Devicetree: Initialization order of mmc block devices?

[Dirk Behme]

On 20.07.2012 13:56, Jassi Brar wrote:
> On 20 July 2012 17:00, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>> On 19.07.2012 22:45, Jassi Brar wrote:
> 
>>>> This problem can occur on many devices with embedded MMC and removable
>>>> SD,
>>>> e.g. smart phones. So I think we should find an solution to define MMC
>>>> scan
>>>> order or device number/name in a device tree.
>>>>
>>> I assume your issue is that due to async nature of mmc scanning, the
>>> eMMC is detected later than external card, despite being the probe for
>>> eMMC's slot initiated first ?
>>> If so, we can do by simply associating 'N' of 'mmcblkN' with the slot
>>> index i.e, mmc_host.index (instead of mmc_blk_data.name_idx). Which is
>>> always in the order of probe calling. And we don't need to modify, or
>>> expect more of, DT for that.
>>
>> Do you mean something like
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -1536,7 +1536,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
>> mmc_card *card,
>>          */
>>
>>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
>> -                "mmcblk%d%s", md->name_idx, subname ? subname : "");
>> +                "mmcblk%d%s", card->host->index, subname ? subname : "");
>>
>>         blk_queue_logical_block_size(md->queue.queue, 512);
>>         set_capacity(md->disk, size);
>>
>> ?
>>
> Exactly!
> It seems too trivial and default for the author to have missed it, so
> I suspect I am overlooking something yet again. I would dig email
> archives to know more about that naming convention before dare submit
> a patch :)

What's about anything like this [1]?

Best regards

Dirk

[1]

---
  drivers/mmc/card/Kconfig |   27 +++++++++++++++++++++++++++
  drivers/mmc/card/block.c |    2 +-
  include/linux/mmc/host.h |    7 +++++++
  3 files changed, 35 insertions(+), 1 deletion(-)

Index: a/drivers/mmc/card/Kconfig
===================================================================
--- a/drivers/mmc/card/Kconfig
+++ b/drivers/mmc/card/Kconfig
@@ -50,6 +50,33 @@ config MMC_BLOCK_BOUNCE

  	  If unsure, say Y here.

+config MMC_SLOTINDEX
+	bool "Use host index for enumerating mmxblkN"
+	depends on MMC_BLOCK
+	default n
+	help
+	  On embedded devices, often there is a combination of
+	  removable mmc devices (e.g. MMC/SD cards) and hard
+	  wired ones (e.g. eMMC). Depending on the hardware
+	  configuration, the 'mmcblkN' node might change if
+	  the removable device is available or not at boot time.
+
+	  E.g. if the removable device is attached at boot time,
+	  it might become mmxblk0. And the hard wired one mmcblk1.
+	  But if the removable device isn't there at boot time,
+	  the hard wired one will become mmcblk0. This makes it
+	  somehow difficult to hard code the root device to the
+	  non-removable device and boot fast.
+
+	  Enabling this option will simply associating 'N' of
+	  'mmcblkN' with the slot index instead of the dynamic
+	  name index. The slot index is always the same, ensuring
+	  that the non-removable mmc device is associated always
+	  with the same mmcblkN. Independent of the availability of
+	  the removable one.
+
+	  If unsure, say N here.
+
  config SDIO_UART
  	tristate "SDIO UART/GPS class support"
  	help
Index: a/drivers/mmc/card/block.c
===================================================================
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1536,7 +1536,7 @@ static struct mmc_blk_data *mmc_blk_allo
  	 */

  	snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
-		 "mmcblk%d%s", md->name_idx, subname ? subname : "");
+		 "mmcblk%d%s", NAMEIDX, subname ? subname : "");

  	blk_queue_logical_block_size(md->queue.queue, 512);
  	set_capacity(md->disk, size);
Index: a/include/linux/mmc/host.h
===================================================================
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -437,4 +437,11 @@ static inline unsigned int mmc_host_clk_
  	return host->ios.clock;
  }
  #endif
+
+#ifdef CONFIG_MMC_SLOTINDEX
+#define NAMEIDX (card->host->index)
+#else
+#define NAMEIDX (md->name_idx)
+#endif
+
  #endif /* LINUX_MMC_HOST_H */

Devicetree: Initialization order of mmc block devices?

[Dirk Behme]

On 20.07.2012 13:56, Jassi Brar wrote:
> On 20 July 2012 17:00, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>> On 19.07.2012 22:45, Jassi Brar wrote:
> 
>>>> This problem can occur on many devices with embedded MMC and removable
>>>> SD,
>>>> e.g. smart phones. So I think we should find an solution to define MMC
>>>> scan
>>>> order or device number/name in a device tree.
>>>>
>>> I assume your issue is that due to async nature of mmc scanning, the
>>> eMMC is detected later than external card, despite being the probe for
>>> eMMC's slot initiated first ?
>>> If so, we can do by simply associating 'N' of 'mmcblkN' with the slot
>>> index i.e, mmc_host.index (instead of mmc_blk_data.name_idx). Which is
>>> always in the order of probe calling. And we don't need to modify, or
>>> expect more of, DT for that.
>>
>> Do you mean something like
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -1536,7 +1536,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
>> mmc_card *card,
>>          */
>>
>>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
>> -                "mmcblk%d%s", md->name_idx, subname ? subname : "");
>> +                "mmcblk%d%s", card->host->index, subname ? subname : "");
>>
>>         blk_queue_logical_block_size(md->queue.queue, 512);
>>         set_capacity(md->disk, size);
>>
>> ?
>>
> Exactly!
> It seems too trivial and default for the author to have missed it, so
> I suspect I am overlooking something yet again. I would dig email
> archives to know more about that naming convention before dare submit
> a patch :)

What's about anything like this [1]?

Best regards

Dirk

[1]

---
  drivers/mmc/card/Kconfig |   27 +++++++++++++++++++++++++++
  drivers/mmc/card/block.c |    2 +-
  include/linux/mmc/host.h |    7 +++++++
  3 files changed, 35 insertions(+), 1 deletion(-)

Index: a/drivers/mmc/card/Kconfig
===================================================================
--- a/drivers/mmc/card/Kconfig
+++ b/drivers/mmc/card/Kconfig
@@ -50,6 +50,33 @@ config MMC_BLOCK_BOUNCE

  	  If unsure, say Y here.

+config MMC_SLOTINDEX
+	bool "Use host index for enumerating mmxblkN"
+	depends on MMC_BLOCK
+	default n
+	help
+	  On embedded devices, often there is a combination of
+	  removable mmc devices (e.g. MMC/SD cards) and hard
+	  wired ones (e.g. eMMC). Depending on the hardware
+	  configuration, the 'mmcblkN' node might change if
+	  the removable device is available or not at boot time.
+
+	  E.g. if the removable device is attached at boot time,
+	  it might become mmxblk0. And the hard wired one mmcblk1.
+	  But if the removable device isn't there at boot time,
+	  the hard wired one will become mmcblk0. This makes it
+	  somehow difficult to hard code the root device to the
+	  non-removable device and boot fast.
+
+	  Enabling this option will simply associating 'N' of
+	  'mmcblkN' with the slot index instead of the dynamic
+	  name index. The slot index is always the same, ensuring
+	  that the non-removable mmc device is associated always
+	  with the same mmcblkN. Independent of the availability of
+	  the removable one.
+
+	  If unsure, say N here.
+
  config SDIO_UART
  	tristate "SDIO UART/GPS class support"
  	help
Index: a/drivers/mmc/card/block.c
===================================================================
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1536,7 +1536,7 @@ static struct mmc_blk_data *mmc_blk_allo
  	 */

  	snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
-		 "mmcblk%d%s", md->name_idx, subname ? subname : "");
+		 "mmcblk%d%s", NAMEIDX, subname ? subname : "");

  	blk_queue_logical_block_size(md->queue.queue, 512);
  	set_capacity(md->disk, size);
Index: a/include/linux/mmc/host.h
===================================================================
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -437,4 +437,11 @@ static inline unsigned int mmc_host_clk_
  	return host->ios.clock;
  }
  #endif
+
+#ifdef CONFIG_MMC_SLOTINDEX
+#define NAMEIDX (card->host->index)
+#else
+#define NAMEIDX (md->name_idx)
+#endif
+
  #endif /* LINUX_MMC_HOST_H */

Re: Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 26 July 2012 14:46, Dirk Behme <dirk.behme@de.bosch.com> wrote:

> ---
>  drivers/mmc/card/Kconfig |   27 +++++++++++++++++++++++++++
>  drivers/mmc/card/block.c |    2 +-
>  include/linux/mmc/host.h |    7 +++++++
>  3 files changed, 35 insertions(+), 1 deletion(-)
>
> Index: a/drivers/mmc/card/Kconfig
> ===================================================================
> --- a/drivers/mmc/card/Kconfig
> +++ b/drivers/mmc/card/Kconfig
> @@ -50,6 +50,33 @@ config MMC_BLOCK_BOUNCE
>
>           If unsure, say Y here.
>
> +config MMC_SLOTINDEX
> +       bool "Use host index for enumerating mmxblkN"
> +       depends on MMC_BLOCK
> +       default n
> +       help
> +         On embedded devices, often there is a combination of
> +         removable mmc devices (e.g. MMC/SD cards) and hard
> +         wired ones (e.g. eMMC). Depending on the hardware
> +         configuration, the 'mmcblkN' node might change if
> +         the removable device is available or not at boot time.
> +
> +         E.g. if the removable device is attached at boot time,
> +         it might become mmxblk0. And the hard wired one mmcblk1.
> +         But if the removable device isn't there at boot time,
> +         the hard wired one will become mmcblk0. This makes it
> +         somehow difficult to hard code the root device to the
> +         non-removable device and boot fast.
> +
> +         Enabling this option will simply associating 'N' of
> +         'mmcblkN' with the slot index instead of the dynamic
> +         name index. The slot index is always the same, ensuring
> +         that the non-removable mmc device is associated always
> +         with the same mmcblkN. Independent of the availability of
> +         the removable one.
> +
> +         If unsure, say N here.
> +
>  config SDIO_UART
>         tristate "SDIO UART/GPS class support"
>         help
> Index: a/drivers/mmc/card/block.c
> ===================================================================
>
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -1536,7 +1536,7 @@ static struct mmc_blk_data *mmc_blk_allo
>          */
>
>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> -                "mmcblk%d%s", md->name_idx, subname ? subname : "");
> +                "mmcblk%d%s", NAMEIDX, subname ? subname : "");
>
>
>         blk_queue_logical_block_size(md->queue.queue, 512);
>         set_capacity(md->disk, size);
> Index: a/include/linux/mmc/host.h
> ===================================================================
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -437,4 +437,11 @@ static inline unsigned int mmc_host_clk_
>         return host->ios.clock;
>  }
>  #endif
> +
> +#ifdef CONFIG_MMC_SLOTINDEX
> +#define NAMEIDX (card->host->index)
> +#else
> +#define NAMEIDX (md->name_idx)
> +#endif
> +
>  #endif /* LINUX_MMC_HOST_H */

I would suggest first attempting the original patch ...

        snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
-                "mmcblk%d%s", md->name_idx, subname ? subname : "");
+                "mmcblk%d%s", card->host->index, subname ? subname : "");


That would either provide the simplest solution to the problem or
teach us the importance of current naming scheme, in which case you
could try this patch :)

Devicetree: Initialization order of mmc block devices?

[Jassi Brar]

On 26 July 2012 14:46, Dirk Behme <dirk.behme@de.bosch.com> wrote:

> ---
>  drivers/mmc/card/Kconfig |   27 +++++++++++++++++++++++++++
>  drivers/mmc/card/block.c |    2 +-
>  include/linux/mmc/host.h |    7 +++++++
>  3 files changed, 35 insertions(+), 1 deletion(-)
>
> Index: a/drivers/mmc/card/Kconfig
> ===================================================================
> --- a/drivers/mmc/card/Kconfig
> +++ b/drivers/mmc/card/Kconfig
> @@ -50,6 +50,33 @@ config MMC_BLOCK_BOUNCE
>
>           If unsure, say Y here.
>
> +config MMC_SLOTINDEX
> +       bool "Use host index for enumerating mmxblkN"
> +       depends on MMC_BLOCK
> +       default n
> +       help
> +         On embedded devices, often there is a combination of
> +         removable mmc devices (e.g. MMC/SD cards) and hard
> +         wired ones (e.g. eMMC). Depending on the hardware
> +         configuration, the 'mmcblkN' node might change if
> +         the removable device is available or not at boot time.
> +
> +         E.g. if the removable device is attached at boot time,
> +         it might become mmxblk0. And the hard wired one mmcblk1.
> +         But if the removable device isn't there at boot time,
> +         the hard wired one will become mmcblk0. This makes it
> +         somehow difficult to hard code the root device to the
> +         non-removable device and boot fast.
> +
> +         Enabling this option will simply associating 'N' of
> +         'mmcblkN' with the slot index instead of the dynamic
> +         name index. The slot index is always the same, ensuring
> +         that the non-removable mmc device is associated always
> +         with the same mmcblkN. Independent of the availability of
> +         the removable one.
> +
> +         If unsure, say N here.
> +
>  config SDIO_UART
>         tristate "SDIO UART/GPS class support"
>         help
> Index: a/drivers/mmc/card/block.c
> ===================================================================
>
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -1536,7 +1536,7 @@ static struct mmc_blk_data *mmc_blk_allo
>          */
>
>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> -                "mmcblk%d%s", md->name_idx, subname ? subname : "");
> +                "mmcblk%d%s", NAMEIDX, subname ? subname : "");
>
>
>         blk_queue_logical_block_size(md->queue.queue, 512);
>         set_capacity(md->disk, size);
> Index: a/include/linux/mmc/host.h
> ===================================================================
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -437,4 +437,11 @@ static inline unsigned int mmc_host_clk_
>         return host->ios.clock;
>  }
>  #endif
> +
> +#ifdef CONFIG_MMC_SLOTINDEX
> +#define NAMEIDX (card->host->index)
> +#else
> +#define NAMEIDX (md->name_idx)
> +#endif
> +
>  #endif /* LINUX_MMC_HOST_H */

I would suggest first attempting the original patch ...

        snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
-                "mmcblk%d%s", md->name_idx, subname ? subname : "");
+                "mmcblk%d%s", card->host->index, subname ? subname : "");


That would either provide the simplest solution to the problem or
teach us the importance of current naming scheme, in which case you
could try this patch :)