linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] improve mmc init sequence
@ 2016-03-17  3:41 Shawn Lin
  2016-03-17 10:43 ` Ulf Hansson
  0 siblings, 1 reply; 3+ messages in thread
From: Shawn Lin @ 2016-03-17  3:41 UTC (permalink / raw)
  To: Ulf Hansson, linux-mmc; +Cc: shawn.lin

Hello Ulf,
	I notice we add MMC_CAP2_NO_SDIO to avoid sending sdio commands during 
initialization. So that means we can use it to improve mmc init
sequence if a specific board use one slot just for emmc or sd. But I 
realize that we can move a step further to add more cap2 like NO_SD/
NO_MMC in order to reduce the boot time. Does that make sense? If the
answer is *yes*, I am happy to push some patches for it since I have
been doing it on my local tree and testing for a long time.

-- 
Best Regards
Shawn Lin


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC] improve mmc init sequence
  2016-03-17  3:41 [RFC] improve mmc init sequence Shawn Lin
@ 2016-03-17 10:43 ` Ulf Hansson
  2016-03-17 10:55   ` Jaehoon Chung
  0 siblings, 1 reply; 3+ messages in thread
From: Ulf Hansson @ 2016-03-17 10:43 UTC (permalink / raw)
  To: Shawn Lin; +Cc: linux-mmc

On 17 March 2016 at 04:41, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> Hello Ulf,
>         I notice we add MMC_CAP2_NO_SDIO to avoid sending sdio commands
> during initialization. So that means we can use it to improve mmc init
> sequence if a specific board use one slot just for emmc or sd. But I realize
> that we can move a step further to add more cap2 like NO_SD/
> NO_MMC in order to reduce the boot time. Does that make sense? If the
> answer is *yes*, I am happy to push some patches for it since I have
> been doing it on my local tree and testing for a long time.

I am not against it, so please go ahead!

Although, you need to give some proof of the amount of saved boot time
(or better the decreased initialization time of a couple of different
cards).

Kind regards
Uffe

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC] improve mmc init sequence
  2016-03-17 10:43 ` Ulf Hansson
@ 2016-03-17 10:55   ` Jaehoon Chung
  0 siblings, 0 replies; 3+ messages in thread
From: Jaehoon Chung @ 2016-03-17 10:55 UTC (permalink / raw)
  To: Ulf Hansson, Shawn Lin; +Cc: linux-mmc

On 03/17/2016 07:43 PM, Ulf Hansson wrote:
> On 17 March 2016 at 04:41, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>> Hello Ulf,
>>         I notice we add MMC_CAP2_NO_SDIO to avoid sending sdio commands
>> during initialization. So that means we can use it to improve mmc init
>> sequence if a specific board use one slot just for emmc or sd. But I realize
>> that we can move a step further to add more cap2 like NO_SD/
>> NO_MMC in order to reduce the boot time. Does that make sense? If the
>> answer is *yes*, I am happy to push some patches for it since I have
>> been doing it on my local tree and testing for a long time.
> 
> I am not against it, so please go ahead!
> 
> Although, you need to give some proof of the amount of saved boot time
> (or better the decreased initialization time of a couple of different
> cards).

I have already tested with similar sequence..I have remembered there is a benefit for decreasing the booting time.
But i didn't remember how much time is decreased...because it wast too long time ago.

Best Regards,
Jaehoon Chung

> 
> Kind regards
> Uffe
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-03-17 10:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-17  3:41 [RFC] improve mmc init sequence Shawn Lin
2016-03-17 10:43 ` Ulf Hansson
2016-03-17 10:55   ` Jaehoon Chung

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).