From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751861AbcDNBZg (ORCPT ); Wed, 13 Apr 2016 21:25:36 -0400 Received: from mailout1.samsung.com ([203.254.224.24]:37352 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750933AbcDNBZe (ORCPT ); Wed, 13 Apr 2016 21:25:34 -0400 X-AuditID: cbfee68f-f79c86d0000012ad-ca-570ef18a1468 Message-id: <570EF189.7030305@samsung.com> Date: Thu, 14 Apr 2016 10:25:29 +0900 From: Jaehoon Chung User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-version: 1.0 To: Ulf Hansson Cc: linux-mmc , Adrian Hunter , Jisheng Zhang , Peter Hurley , Laszlo Fiat , "linux-kernel@vger.kernel.org" , Linus Torvalds , "# 4.0+" Subject: Re: [PATCH] mmc: block: Use the mmc host device index as the mmcblk device index References: <1460015861-14004-1-git-send-email-ulf.hansson@linaro.org> <57064D96.1050402@samsung.com> In-reply-to: Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsWyRsSkWLfrI1+4wcLTYhYnn6xhs3h3fDeL xZu2djaLy7vmsFkc+d/PaHHs0j9GiwUbHzFaPOp7y25xfG24A6fHzll32T1W/FnP5rF4z0sm jzvX9rB5nJjxm8Vj8sKLzB6fN8kFsEdx2aSk5mSWpRbp2yVwZZzcdoOp4Jt0xe4ji5gbGFeJ dTFyckgImEhMm7WPFcIWk7hwbz0biC0ksIJR4tdkb5iavp8tTF2MXEDxpYwSD640MkM4Dxgl /p3tBOvmFdCS6Fs5kRnEZhFQlXj69STYJDYBHYnt344zgdiiAmESD9bthaoXlPgx+R4LiC0i oCGx5+F5VpChzAIPmSQ2TZsO1iwsEC1xedMUqNXrGCW2TlvBDpLgFAiWmLK5E8jmAOpQl5gy JRckzCwgL7F5zVuw6yQEvrJLLJ32gR3iIgGJb5MPsYDUSwjISmw6wAzxmqTEwRU3WCYwis1C ctMshKmzkExdwMi8ilE0tSC5oDgpvchYrzgxt7g0L10vOT93EyMwOk//e9a/g/HuAetDjAIc jEo8vBfW8IYLsSaWFVfmHmI0BTpiIrOUaHI+MAXklcQbGpsZWZiamBobmVuaKYnzLpT6GSwk kJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsT7xxeFJF/cf2ZXftcbn9755fSlnZaRvnzx1nPvD iVa1oEbti1WTszbX394qnbkw7Yhwdw0Ta1VU/lJZXbH3sxfu0PjKKdR2YdsMFa6p7Kn3668z yZvN3VwnE5K1dFXGolSB8snHH/b+vXjEJzGnKVH8d8zs4yF7lIP03+j0CIn/KD8Q3m/co8RS nJFoqMVcVJwIAC1h31LJAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42I5/e+xgG7XR75wgx+3BCxOPlnDZvHu+G4W izdt7WwWl3fNYbM48r+f0eLYpX+MFgs2PmK0eNT3lt3i+NpwB06PnbPusnus+LOezWPxnpdM Hneu7WHzODHjN4vH5IUXmT0+b5ILYI9qYLTJSE1MSS1SSM1Lzk/JzEu3VfIOjneONzUzMNQ1 tLQwV1LIS8xNtVVy8QnQdcvMATpNSaEsMacUKBSQWFyspG+HaUJoiJuuBUxjhK5vSBBcj5EB GkhYw5hxctsNpoJv0hW7jyxibmBcJdbFyMkhIWAi0fezhQnCFpO4cG89WxcjF4eQwFJGiQdX GpkhnAeMEv/OdrKCVPEKaEn0rZzIDGKzCKhKPP16kg3EZhPQkdj+7TjYJFGBMIkH6/ZC1QtK /Jh8jwXEFhHQkNjz8DwryFBmgYdMEpumTQdrFhaIlri8aQoTxLZ1jBJbp61gB0lwCgRLTNnc CWRzAHWoS0yZkgsSZhaQl9i85i3zBEaBWUh2zEKomoWkagEj8ypGidSC5ILipPRcw7zUcr3i xNzi0rx0veT83E2M4BTwTGoH48Fd7ocYBTgYlXh4L6zhDRdiTSwrrsw9xCjBwawkwnvxA1+4 EG9KYmVValF+fFFpTmrxIUZTYCBMZJYSTc4Hpqe8knhDYxMzI0sjc0MLI2NzJXHex//XhQkJ pCeWpGanphakFsH0MXFwSjUwRjik81WxLur/XrmLNf7VpWiu38WH9e8oygZEbo9pX/xilbxR iM3UnVv+spef6+Gecufl1DWv5gkpn5zMaqH3PYwtKBpo9Pd5NVPNBbcUyqq7yhx637t6Pmsh G6v6uUmXssQ/fDX0iFTYYRp7+NDXnDuf1vGVrv+xUnt63NqcS2ZvRR5sTt+ixFKckWioxVxU nAgAomCKUxcDAAA= DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 > >