On 2 February 2015 at 10:02, addy ke <addy.ke@xxxxxxxxxxxxxx> wrote: > > > On 2015/2/2 16:17, Ulf Hansson wrote: >> On 2 February 2015 at 09:16, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >>>>> >>>>> about bus_ops->alive, I think it can't use in tuning state. >>>>> Because: >>>>> bus_ops->alive() --> mmc_sd_alive(host) /* sd card */ -->mmc_send_status(host->card, NULL); >>>>> But host->card == NULL in tuning state(mmc_sd_init_card->mmc_sd_init_uhs_card). >>>>> >>>>> Only if sd is initialized successfully, we can get card pointer by host->card. >>>>> see: mmc_sd_init_card(drivers/mmc/core/sd.c), the end of this function: host->card = card >>>> And bus_ops->alive only check whether mmc is alive or not, the second parameter(*status) is NULL, >>>> We can not get the card status. >>>> But in tuning state, we need wait until card is idle, if the previous tuning is failed. >>> >>> You are right that we can't use bus_ops->alive() in its current form. >>> Changing it to take "card" and "status" as parameter should fix this >>> for us. My point was more that we can't use mmc_send_status() since >>> that doesn't work for SDIO. > > For sdio, I think maybe we can use CMD7 to get sdio status. > > And there are 3 file which need get card status at least: > 1. drivers/mmc/core/mmc_ops.c: mmc_send_status() > 2. drivers/mmc/card/block.c: get_card_status() > 3. drivers/mmc/card/mmc_test.c: mmc_test_wait_busy() > Maybe we need merge them and provide uniform interface for them. > >>> >>> Anyway, it seems like we need to put this patchset on hold for a while. >>> >>> You I merge the below patch instead so we at least have something >> >> /s /You / Should >> >>> working for 3.20? > This patch can work, but it need delay 10ms each tuning. > It is too slow to initialize the card(tuning time >= (10 * tuning_count) ms) Yes, it seems like it's not the perfect solution, but what options do we have right now? Leave it as is or should I apply below patch? Jaehoon, what's your view on this? >>> >>> [PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY >>> https://lkml.org/lkml/2015/1/13/562 >>> Kind regards Uffe -- 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