Re: New MMC maintainer needed

[Nicolas Pitre]

On Thu, 13 Aug 2009, Adrian Hunter wrote:

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

I therefore tend to agree with Pierre and Andrew.  This doesn't make 
enough of a difference to increase the complexity and maintenance cost 
of the code for such a trivial improvement.

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

Simply commenting out the SD/SDIO or MMC probe call in the code is 
very simple when you're debugging.  Then if you actually come to the 
conclusion that some real bugs are due to this cross probe and can prove 
it then we might reconsider.

Currently, generic host drivers are sometimes used in the context of a 
uSD slot, sometimes in the context of a SD/SDIO/MMC slot, sometimes with 
a hardwired SDIO based chip soldered on the board, and they don't need 
any special flags to distinguish between those use cases.  This greatly 
helps maintainability, and that should prevail over slight latency 
improvements to non timing critical events such as card insertion.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/