[U-Boot] [RFC PATCH] mmc: Skipping the MMC initialization at the boot time

[Michal Simek]

Hi Jaehoon,

On 23.1.2018 10:29, Siva Durga Prasad Paladugu wrote:
> Hi Jaehoon,
> 
>> -----Original Message-----
>> From: Jaehoon Chung [mailto:jh80.chung at samsung.com]
>> Sent: Tuesday, January 23, 2018 7:23 AM
>> To: Siva Durga Prasad Paladugu <sivadur at xilinx.com>; u-
>> boot at lists.denx.de
>> Cc: Vipul Kumar <vipulk at xilinx.com>
>> Subject: Re: [RFC PATCH] mmc: Skipping the MMC initialization at the boot
>> time
>>
>> Hi Siva,
>>
>> On 01/22/2018 08:03 PM, Siva Durga Prasad Paladugu wrote:
>>> Hi Jaehoon,
>>>
>>>> -----Original Message-----
>>>> From: Jaehoon Chung [mailto:jh80.chung at samsung.com]
>>>> Sent: Thursday, January 18, 2018 1:46 PM
>>>> To: Siva Durga Prasad Paladugu <sivadur at xilinx.com>; u-
>>>> boot at lists.denx.de
>>>> Cc: Vipul Kumar <vipulk at xilinx.com>; Vipul Kumar <vipulk at xilinx.com>;
>>>> Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>>> Subject: Re: [RFC PATCH] mmc: Skipping the MMC initialization at the
>>>> boot time
>>>>
>>>> On 01/18/2018 02:40 PM, Siva Durga Prasad Paladugu wrote:
>>>>> From: Vipul Kumar <vipul.kumar at xilinx.com>
>>>>>
>>>>> By enabling CONFIG_SKIP_EARLY_MMC_INIT config, user can skip the
>>>> MMC
>>>>> initialization at the boot time. After getting the u-boot console,
>>>>> user can select the device using mmc dev and can communicate with
>> that.
>>>>> This is useful where user don't want to perform mmc initialization
>>>>> while booting and can do explicitly later as per choice.
>>>>
>>>> Is there any use-case? What benefit can user have with this config?
>>>> According to commit-msg, user will choose the mmc device later.
>>>> Is it same with initializing at booting time?
>>> Yes, there may be case, where we have both controllers enabled but
>>> user would like to Communicate with only one at u-boot and this
>>> selection also depends on environment Or something which will be
>>> updated from external world then in this case, user will initialize
>>> Later as per his wish. This may save bootime as it initializes only
>>> the required one and choice of which one to initialize
>>
>> Then did you check how much time can save?
> I didn’t measured, but it will definitely decrease eventhough it can be minimal.
>> If user want to save the booting time, will not enter to uboot console?
> Yes, user doesn’t need to enter u-boot console, he can simply execute boot command as per environment
> and that env may contain corresponding/required mmc init only.
> 
>> Well..I didn't agree about saving the booting time.
>>
>> If you need to add this config, could you explain in more detail.
>> And how many board do enable this config in ./configs/ ?
> 
> I see it as an option, anyone can enable if they see value for them or
> need boot time improvement.
> For me, it's just one config in configs/ as of now.

Let me also come to this discussion. Another usage of this would be with
broken HW or incorrect SW configurations.

Right now initialization at boot time is what u-boot is using for long
time for "old" subsystems.
For others this is done based on request. qspi - sf probe, usb - usb
start, scsi - scsi start and maybe others.

And this "feature" (I am not saying it is done properly) is just adding
option to initialize it based on request as is done for others
subsystems which we use today.
Based on current u-boot behavior for some subsystems I think it is
reasonable to defer mmc probe as is done for qspi, usb, scsi and almost
doesn't matter what's the reason for doing that (Incorrect HW,
configuration, time, etc).

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180123/9289613f/attachment.sig>