From patchwork Thu Jul 26 09:16:43 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dirk Behme X-Patchwork-Id: 1240951 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork1.kernel.org (Postfix) with ESMTP id 464A93FC5A for ; Thu, 26 Jul 2012 09:23:43 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SuKEc-0003VU-8c; Thu, 26 Jul 2012 09:19:54 +0000 Received: from smtp2-v.fe.bosch.de ([139.15.237.6]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1SuKEM-0003V8-0S for linux-arm-kernel@lists.infradead.org; Thu, 26 Jul 2012 09:19:39 +0000 Received: from vsmta11.fe.internet.bosch.com (unknown [10.4.98.30]) by imta24.fe.bosch.de (Postfix) with ESMTP id 415BDB00219; Thu, 26 Jul 2012 11:19:33 +0200 (CEST) Received: from localhost (vsgw2.fe.internet.bosch.com [10.4.98.13]) by vsmta11.fe.internet.bosch.com (Postfix) with SMTP id 39B9143C0688; Thu, 26 Jul 2012 11:19:33 +0200 (CEST) Received: from FE-PUB1000.de.bosch.com (10.3.153.167) by si-hub05.de.bosch.com (10.3.153.47) with Microsoft SMTP Server (TLS) id 8.3.264.0; Thu, 26 Jul 2012 11:19:16 +0200 Received: from SI-HUB1000.de.bosch.com (10.4.103.106) by FE-PUB1000.de.bosch.com (10.3.153.167) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 26 Jul 2012 11:19:17 +0200 Received: from [10.34.217.145] (10.34.217.145) by SI-HUB1000.de.bosch.com (10.4.103.106) with Microsoft SMTP Server id 14.2.309.2; Thu, 26 Jul 2012 11:19:17 +0200 Message-ID: <50110AFB.9090300@de.bosch.com> Date: Thu, 26 Jul 2012 11:16:43 +0200 From: Dirk Behme Organization: Robert Bosch Car Multimedia GmbH User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "linux-mmc@vger.kernel.org" Subject: Re: Devicetree: Initialization order of mmc block devices? References: <5006571A.7060103@de.bosch.com> <50068696.8070408@de.bosch.com> <5006C40D.300@de.bosch.com> <50094168.2090900@de.bosch.com> In-Reply-To: X-Originating-IP: [10.34.217.145] X-Spam-Note: CRM114 invocation failed X-Spam-Score: -6.9 (------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-6.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [139.15.237.6 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Jassi Brar , Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , "Wohlrab Knut \(CM-AI/PJ-CA33\)" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On 20.07.2012 13:56, Jassi Brar wrote: > On 20 July 2012 17:00, Dirk Behme 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 */