Matt Fleming wrote:
On Mon, Aug 03, 2009 at 02:13:28PM +0300, Adrian Hunter wrote:
Pierre Ossman wrote:
Con:

 - The scanning code gets less clear as you increase the number of
   possible paths through it.

 - Different systems will have different init sequences, possibly
   provoking bugs in the cards.

 - Host driver writers now have more capability bits they have to
   consider. And these might be less than obvious since SD/MMC/SDIO are
   normally compatible so these bits seem useless.

 - With the current logic (which was better in the first version),
   "normal" drivers will have to explicitly state that they work as
   intended by setting all bits.
And the pro is objective.

Pro:

 - A slightly reduced scanning time.
That's great!  Why do you disregard this so easily?


Ping. Adrian, do you have any initialisation times for this patch? I'm
afraid I don't have any eMMC hardware, so I'm not able to gather any
numbers.


Sorry for the slow reply.

Results in microseconds:

        before          after
eMMC    194145          193641
uSD     4143            2129

However, that excludes powering up.  For example the pbias setting
on omap_hsmmc for MMC1 (uSD for us) has a 100ms delay.

So the difference is negligible.

Although, the notion of unnecessarily sending SDIO commands
to an uSD, and SDIO and SD commands to an eMMC, seems wrong.
Especially when trying to debug very-hard-to-reproduce errors.


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

Reply via email to