On 26 January 2015 at 18:45, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > Ulf, > > On Mon, Jan 26, 2015 at 7:15 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> On 26 January 2015 at 12:19, Addy Ke <addy.ke@xxxxxxxxxxxxxx> wrote: >>> We need to take the card pointer in execute_tuning() for mmc_send_status(), >> >> mmc_send_status() is an mmc core function, not intended for host's to call. >> >>> but mmc->card is NULL in tuning state. So we need change the first parameter >>> of execute_tuning() to card pointer(struct mmc_card * card). >> >> So, why do we need this? > > I asked Addy to post upstream against mmc_send_tuning(), but I guess > he didn't (he posted against Alex's NAKed patch instead). > > ...when I talked to him about it, Addy was asserting that when tuning > fails it is important (at least on dw_mmc on rk3288) that we wait for > the card to stop being busy and that the way to detect was using > mmc_send_status(). So, could that be due to the internal logic of the error handling in dw_mmc driver? Or you think this is a generic issue? According to the specifications (eMMC and SD) both states that the tuning command has an R1 response. So, there shouldn't be any busy signalling involved - at least according to spec. > > That would mean that against upstream you'd need to change > mmc_send_tuning() to take in the card as well (or move the "host->card > = card" assignment to before UHS init, which seems less desirable?) > > What do you think about that? Is there a better solution? Why do we need to change mmc_send_tuning()? I thought the issue was that mmc_send_status(), which currently takes "card" as a parameter. 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
