[PATCH 1/2] mmc: core: use card pointer as the first parameter of execute_tuning()

[Jaehoon Chung]

On 02/04/2015 09:54 PM, Ulf Hansson wrote:
> On 2 February 2015 at 10:02, addy ke <addy.ke at rock-chips.com> wrote:
>>
>>
>> On 2015/2/2 16:17, Ulf Hansson wrote:
>>> On 2 February 2015 at 09:16, Ulf Hansson <ulf.hansson at linaro.org> 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?

It's not the best solution, but if needs to use this, we need to apply the other approach in future.
Well, i'm working other job..I think i can start to work for dw-mmc on next-week.
I think good that the below patch should be merged at first.
Then try to find and discuss more generic solution, how about?

Best Regards,
Jaehoon Chung

> 
>>>>
>>>> [PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY
>>>> https://lkml.org/lkml/2015/1/13/562
>>>>
> 
> Kind regards
> Uffe
>