linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: knut.wohlrab@de.bosch.com (Knut Wohlrab)
To: linux-arm-kernel@lists.infradead.org
Subject: Devicetree: Initialization order of mmc block devices?
Date: Wed, 18 Jul 2012 11:49:10 +0200	[thread overview]
Message-ID: <50068696.8070408@de.bosch.com> (raw)
In-Reply-To: <CAJe_ZhcY78ah81zsfwXxE=bMG4o6v9RwZV_DQyUj7g=d-1hR_w@mail.gmail.com>

On 07/18/2012 09:23 AM, Jassi Brar wrote:
> On 18 July 2012 11:56, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>> Similar to [1] we have a device which has two mmc block devices connected:
>> One external removable and a second internal hard wired one. Depending on
>> the availability of the external removable mmc card at boot time, the
>> internal hard wired device becomes mmcblk1 (external mmc card available ==
>> mmcblk0) or mmcblk0 if the external one is not there. This order is given by
>> the hardware.
>>
>> With older, non-DT kernels, we used the hack from [2] to control the
>> initialization order and force the internal hard wired device to mmcblk0.
>>
>> Now, we are switching to a newer, DT based kernel. With a DT based kernel
>> this hack doesn't seem to work an more.
>>
>> Any idea how we could influence the initialization order of the mmc block
>> devices using a DT based kernel? Ensuring that the internal, hard wired mmc
>> card is always mapped to mmcblk0?
>>
> Doesn't it work by simply by moving the "internal" element before
> "external" in the array 'struct twl4030_hsmmc_info mmc[]' ?

Thanks a lot for quick response. Yes, the order of MMC devices in the 
hardware definition of a board file is a possible solution. But we are 
using a device tree file (*.dts) with this definitions:
...
usdhc at 02198000 { /* uSDHC3, eMMC */
     fsl,card-wired;
     status = "okay";
};

usdhc at 02190000 { /* uSDHC1, SD card */
     cd-gpios = <&gpio1 4 0>;
     wp-gpios = <&gpio1 2 0>;
     status = "okay";
};
....
The order of the entries doesn't matter. The SDHC controller 1 is probed 
first. 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 ...").

Is there any solution to define a scan order or a MMC device number/name 
with a device tree?

Thanks a lot and best regards

Knut

  reply	other threads:[~2012-07-18  9:49 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 [this message]
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
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=50068696.8070408@de.bosch.com \
    --to=knut.wohlrab@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).