Hi,
On Mon, Mar 26 2012, Magnus Damm wrote:
>> Do you have a feeling of if it it worth trying to start with a value close
>> to 400kHz or if it would be better to simplify the code? I can try and
>> measure the difference in start up time for particular hardware
>> combinations, but I'm not sure how far that will get us.
>
> I believe the correct way is to program the hardware to be as close to
> 400 kHz as possible. I may be wrong, but I guess that slower than 400
> kHz is also acceptable during the initial phase, but faster may mean
> out of spec. For optimal performance the code may need to be reworked
> to support both correct and slow 400 kHz as well as whatever high
> frequencies needed for fast transfers.
Hm, I think I'm missing something -- you shouldn't need to optimize f_min
in the driver at all, because the core handles retrying at lower frequencies
in the init phase (before switching to the higher frequency that comes from
the CSD) and it always begins at 400KHz if that's above f_min. In core.c:
void mmc_rescan(struct work_struct *work)
{
static const unsigned freqs[] = { 400000, 300000, 200000, 100000 };
...
for (i = 0; i < ARRAY_SIZE(freqs); i++) {
if (!mmc_rescan_try_freq(host, max(freqs[i], host->f_min)))
...
So, why would you want f_min to be near 400KHz?
Thanks,
- Chris.
--
Chris Ball <cjb@xxxxxxxxxx> <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
