All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dirk Behme <dirk.behme@de.bosch.com>
To: Jassi Brar <jaswinder.singh@linaro.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Wohlrab Knut (CM-AI/PJ-CA31)" <Knut.Wohlrab@de.bosch.com>
Subject: Re: Devicetree: Initialization order of mmc block devices?
Date: Fri, 20 Jul 2012 13:30:48 +0200	[thread overview]
Message-ID: <50094168.2090900@de.bosch.com> (raw)
In-Reply-To: <CAJe_Zhcyug17ZnKtmKnVhHT=Mm1PKdE68f21WWkUVtfCwNxSwg@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: dirk.behme@de.bosch.com (Dirk Behme)
To: linux-arm-kernel@lists.infradead.org
Subject: Devicetree: Initialization order of mmc block devices?
Date: Fri, 20 Jul 2012 13:30:48 +0200	[thread overview]
Message-ID: <50094168.2090900@de.bosch.com> (raw)
In-Reply-To: <CAJe_Zhcyug17ZnKtmKnVhHT=Mm1PKdE68f21WWkUVtfCwNxSwg@mail.gmail.com>

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

  reply	other threads:[~2012-07-20 11:30 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-18  6:26 Devicetree: Initialization order of mmc block devices? Dirk Behme
2012-07-18  6:26 ` Dirk Behme
2012-07-18  7:23 ` Jassi Brar
2012-07-18  7:23   ` Jassi Brar
2012-07-18  9:49   ` Knut Wohlrab
2012-07-18  9:49     ` Knut Wohlrab
2012-07-18 13:47     ` Jassi Brar
2012-07-18 13:47       ` Jassi Brar
2012-07-18 14:11       ` Knut Wohlrab
2012-07-18 14:11         ` Knut Wohlrab
2012-07-18 14:54         ` Eric Nelson
2012-07-18 14:54           ` Eric Nelson
2012-07-18 15:16           ` Knut Wohlrab
2012-07-18 15:16             ` Knut Wohlrab
2012-07-19  8:07             ` Thomas Petazzoni
2012-07-19  8:07               ` Thomas Petazzoni
2012-07-19 14:08             ` Matthias Kaehlcke
2012-07-19 14:08               ` Matthias Kaehlcke
2012-07-19 20:45         ` Jassi Brar
2012-07-19 20:45           ` Jassi Brar
2012-07-20 11:30           ` Dirk Behme [this message]
2012-07-20 11:30             ` Dirk Behme
2012-07-20 11:56             ` Jassi Brar
2012-07-20 11:56               ` Jassi Brar
2012-07-26  9:16               ` Dirk Behme
2012-07-26  9:16                 ` Dirk Behme
2012-07-26  9:39                 ` Jassi Brar
2012-07-26  9:39                   ` Jassi Brar
2012-07-19 13:13 ` Arnd Bergmann
2012-07-19 13:13   ` Arnd Bergmann
2012-07-26  8:06   ` Dirk Behme
2012-07-26  8:06     ` Dirk Behme

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50094168.2090900@de.bosch.com \
    --to=dirk.behme@de.bosch.com \
    --cc=Knut.Wohlrab@de.bosch.com \
    --cc=arnd@arndb.de \
    --cc=jaswinder.singh@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.