From: Jaehoon Chung <jh80.chung@samsung.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc <linux-mmc@vger.kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Jisheng Zhang <jszhang@marvell.com>,
Peter Hurley <peter@hurleysoftware.com>,
Laszlo Fiat <laszlo.fiat@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"# 4.0+" <stable@vger.kernel.org>
Subject: Re: [PATCH] mmc: block: Use the mmc host device index as the mmcblk device index
Date: Thu, 14 Apr 2016 10:25:29 +0900 [thread overview]
Message-ID: <570EF189.7030305@samsung.com> (raw)
In-Reply-To: <CAPDyKFpCAjizLOUABuo06_P0PEDTmOARmgwwLShb16PByYDcrg@mail.gmail.com>
Hi Ulf,
Sorry for replying late.
On 04/07/2016 10:07 PM, Ulf Hansson wrote:
> On 7 April 2016 at 14:07, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>> On 04/07/2016 04:57 PM, Ulf Hansson wrote:
>>> Commit 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
>>> simultaneously") causes regressions for some platforms.
>>>
>>> These platforms relies on fixed mmcblk device indexes, instead of
>>> deploying the defacto standard with UUID/PARTUUID. In other words their
>>> rootfs needs to be available at hardcoded paths, like /dev/mmcblk0p2.
>>>
>>> Such guarantees have never been made by the kernel, but clearly the above
>>> commit changes the behaviour. More precisely, because of that the order
>>> changes of how cards becomes detected, so do their corresponding mmcblk
>>> device indexes.
>>>
>>> As the above commit significantly improves boot time for some platforms
>>> (magnitude of seconds), let's avoid reverting this change but instead
>>> restore the behaviour of how mmcblk device indexes becomes picked.
>>>
>>> By using the same index for the mmcblk device as for the corresponding mmc
>>> host device, the probe order of mmc host devices decides the index we get
>>> for the mmcblk device.
>>>
>>> For those platforms that suffers from a regression, one could expect that
>>> this updated behaviour should be sufficient to meet their expectations of
>>> "fixed" mmcblk device indexes.
>>>
>>> Another side effect from this change, is that the same index is used for
>>> the mmc host device, the mmcblk device and the mmc block queue. That
>>> should clarify their relationship.
>>
>> I have tested with this patch..but there also are side-effects.
>> Exynos4 series has the two host controller..one is sdhci, one is dwmmc for eMMC.
>> In this case, dwmmc controller is probed after sdhci controller.
>>
>> Then eMMC is always assigned to mmcblk1.
>
> Okay, let me follow up with some questions.
>
> 1)
> What is the sdhci controller used for?
Some of Exynos4 series have two MMC host controller.
As i mentioned, one is sdhci, other is dwmmc.
sdhci controller can be used for eMMC/SD/SDIO. (emmc, T-flash, WiFi)
And dwmmc controller can be only used for eMMC.
It can choose which controller user uses.
In normal, i recommend the dwmmc controller is used for eMMC.
(There are some reason..I/O performance, and functionality.)
>
> 2)
> Are you seeing regressions for Exynos for this? I was under the
> assumption that your vendor trees contained patches to deal with fixed
> mmcblk ids?
Actually not...but i need to check more..in vendor tress.
>
> 3)
> You proposed [1] recently to use aliases in DT to support fixed mmcblk
> ids. I do realize that as UUID/PARTUUID sometimes can be a bit
> cumbersome to use for an embedded system. Using aliases via DT seems
> like a very good option. To implement that on top of $subject patch
> should be quite easy to fix (I am happy to help with it). Would that
> address your concerns?
I saw this patch was applied in your repository..So i will test with your tree.
In normal case, i think it's not problem...but i remembered there is a rare case about removable case.
I will try to test with all cases..:)
Best Regards,
Jaehoon Chung
>
>>
>> I think it's not good that make another problem for solving something.
>> It needs more discussion for this..
>
> Thanks for testing and your comments!
>
> Kind regards
> Uffe
>
> [1]
> http://www.spinics.net/lists/linux-mmc/msg35980.html
>
>
next prev parent reply other threads:[~2016-04-14 1:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 7:57 [PATCH] mmc: block: Use the mmc host device index as the mmcblk device index Ulf Hansson
2016-04-07 7:57 ` Ulf Hansson
2016-04-07 12:07 ` Jaehoon Chung
2016-04-07 13:07 ` Ulf Hansson
2016-04-14 1:25 ` Jaehoon Chung [this message]
2016-04-14 7:26 ` Ulf Hansson
2016-04-10 18:04 ` Laszlo Fiat
2016-04-11 8:25 ` Ulf Hansson
2016-04-11 12:46 ` Adrian Hunter
2016-04-12 18:15 ` Laszlo Fiat
2016-04-13 11:19 ` Adrian Hunter
2016-04-13 18:19 ` Laszlo Fiat
2016-05-16 8:47 ` Ulf Hansson
2016-05-16 9:12 ` Adrian Hunter
2016-05-16 11:43 ` Adrian Hunter
[not found] ` <5739F7C1.707@gmail.com>
2016-05-16 16:56 ` Laszlo Fiat
2016-05-16 20:30 ` Laszlo Fiat
2016-05-16 21:45 ` Ulf Hansson
2016-05-17 18:11 ` Laszlo Fiat
2016-04-12 6:59 ` Ulf Hansson
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=570EF189.7030305@samsung.com \
--to=jh80.chung@samsung.com \
--cc=adrian.hunter@intel.com \
--cc=jszhang@marvell.com \
--cc=laszlo.fiat@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=peter@hurleysoftware.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=ulf.hansson@linaro.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.