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 */
next prev parent 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).