linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dirk.behme@de.bosch.com (Dirk Behme)
To: linux-arm-kernel@lists.infradead.org
Subject: Devicetree: Initialization order of mmc block devices?
Date: Thu, 26 Jul 2012 11:16:43 +0200	[thread overview]
Message-ID: <50110AFB.9090300@de.bosch.com> (raw)
In-Reply-To: <CAJe_Zhfu-k0V7q527JSqdThn_c7WfNcaHmYOwBBaaRh+A=2hKA@mail.gmail.com>

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 */

  reply	other threads:[~2012-07-26  9:16 UTC|newest]

Thread overview: 16+ 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  7:23 ` Jassi Brar
2012-07-18  9:49   ` Knut Wohlrab
2012-07-18 13:47     ` Jassi Brar
2012-07-18 14:11       ` Knut Wohlrab
2012-07-18 14:54         ` Eric Nelson
2012-07-18 15:16           ` Knut Wohlrab
2012-07-19  8:07             ` Thomas Petazzoni
2012-07-19 14:08             ` Matthias Kaehlcke
2012-07-19 20:45         ` Jassi Brar
2012-07-20 11:30           ` Dirk Behme
2012-07-20 11:56             ` Jassi Brar
2012-07-26  9:16               ` Dirk Behme [this message]
2012-07-26  9:39                 ` Jassi Brar
2012-07-19 13:13 ` Arnd Bergmann
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=50110AFB.9090300@de.bosch.com \
    --to=dirk.behme@de.bosch.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).