> > I am very confused, why do we read the present state register on every > request? > > How long time read the present state register? Even if one line code is performed, I think it need time to complete.
> > My codes are added to the function mmc_sd_detect in file core/sd.c > > Function mmc_rescan has detect the card present state repeatedly, so I > think we don't need to detect the card state on every request. > > So I think the codes to detect the card present state in sdhci_request > should be removed to improve the performance. > > How did you get the performance benefit? Do you know there are many tools to run the performance? IPForward/IPSEC for network, iozone for SATA/SDHC... We have the performance result from our platform, the result will decrease 2%~5%! If the driver has the option 'MMC_CAP_NEEDS_POLL' (many driver enable this option) and the card is always present, the driver will send the command "mmc_send_status" to ask the card state repeatedly. Do you know what it means? Many interrupts will be generated even if the system is reading from/writing to the SD/MMC card. > And mmc_rescan is repeatedly for SD-card? > If mmc_rescan is repeatedly, that reason is the below code. (just my > thinking) > > if (host->caps & MMC_CAP_NEEDS_POLL) > mmc_schedule_delayed_work(&host->detect, HZ); > > what is your point related with mmc_rescan? > I didn't understand yours.. There are some controllers don't support the card detect, the SDHCI_CARD_PRESENT is forever one. And some controller must enable the MMC_CAP_NEEDS_POLL option (about this, you can search the folder mmc/host/), that means mmc_rescan will be run repeatedly. In these cases, if we detect the card state though command mmc_send_status, a lot of interrupts will be generated. For the transaction from/to SD card, we don't need to check the card present state, it should be done in other area. So I don't think it is correct to detect card state in function sdhci_request. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
