Re: Dynamic MMC device naming vs. bootloaders

[Kishore Kadiyala <kishorek.kadiyala@gmail.com>]

On Wed, Apr 6, 2011 at 2:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> Kishore Kadiyala wrote at Tuesday, April 05, 2011 12:38 AM:
>>
>> Hi Stephen,
>>
>> On Mon, Apr 4, 2011 at 11:09 PM, Stephen Warren <swarren@nvidia.com> wrote:
>> > Chris et. al.,
>> >
>> > I'm working on an ARM system that contains at least two MMC/SD devices;
>> > specifically the board has an internal MMC device, and an SD card slot,
>> > although the SoC has four MMC/SD hosts IIRC.
>> >
>> > The kernel's naming of these devices is dynamic. If the SD card is not
>> > plugged in, the internal MMC is always known as mmcblock0. If the SD card
>> > is plugged in too, sometimes the internal MMC is mmcblk0 and sometimes it's
>> > mmcblk1. I assume this is timing related; 2.6.37 usually seemed to name
>> > them "in order", whereas 2.6.38 usually seems to name them "backwards".
>> >
>> > This causes problems with the bootloader scripts I'm using, which assumes
>> > that the internal MMC is always device 0 and the SD slot is always device 1,
>> > and hence provides kernel command-line argument root=/dev/mmcblk0p3 or
>> > root=/dev/mmcblk1p3 based on whether it booted from SD or internal MMC (SD
>> > is searched for a valid image first by the bootloader).
>>
>> Just follow this thread which discusses the same but for OMAP4 controller
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47853.html
>
> Kishore, thanks for the pointer. However, I don't see anything in that thread
> that affects MMC block device IDs. The thread ended with the original poster
> requesting the patch be dropped, since he'd made a mistake in his bootloader
> settings.
>
> Just perhaps the registration order change is enough to change the timing of
> device (memory device, not host controller?) probing, which just happens to
> affect the ID assignment?
>
>> One solution could be make your internal MMC always registered as mmcblk0
>> and the removable one as next device.
>
> That's essentially what the patch I gave previously does.

Your change was in mmc/card/block.c, but you can handle this by
changing sequence during
device registeration.

Following change in the patch does that
https://patchwork.kernel.org/patch/595861/

diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 1a943be..f914099 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -349,11 +349,6 @@  static struct twl4030_usb_data omap4_usbphy_data = {

 static struct omap2_hsmmc_info mmc[] = {
 	{
-		.mmc		= 1,
-		.caps		= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
-		.gpio_wp	= -EINVAL,
-	},
-	{
 		.mmc		= 2,
 		.caps		=  MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
 		.gpio_cd	= -EINVAL,
@@ -361,19 +356,24 @@  static struct omap2_hsmmc_info mmc[] = {
 		.nonremovable   = true,
 		.ocr_mask	= MMC_VDD_29_30,
 	},
+	{
+		.mmc		= 1,
+		.caps		= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+		.gpio_wp	= -EINVAL,
+	},
 	{}	/* Terminator */
 };

Regards,
Kishore

>
> --
> nvpublic
>
>