Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 15 January 2015 at 15:59, Arend van Spriel <arend@xxxxxxxxxxxx> wrote:
> On 01/15/15 15:46, Ulf Hansson wrote:
>>
>> On 15 January 2015 at 15:17, Arend van Spriel<arend@xxxxxxxxxxxx>  wrote:
>>>
>>> On 01/15/15 15:07, Arend van Spriel wrote:
>>>>
>>>>
>>>> On 01/15/15 14:39, Ulf Hansson wrote:
>>>>>
>>>>>
>>>>> On 15 January 2015 at 11:17, Adrian Hunter<adrian.hunter@xxxxxxxxx>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 14/01/15 14:59, Ulf Hansson wrote:
>>>>>>>
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>>>
>>>>>>>>> The value from the register is also just randomly selected, only
>>>>>>>>> difference is that it's the HW that has randomly set it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Presumably the value is chosen based on the maximum rate of
>>>>>>>> temperature
>>>>>>>> change and the corresponding effect that has on the signal.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Even if the above commit was merged, I don't think it was the
>>>>>>>>> correct
>>>>>>>>> way of dealing with re-tuning.
>>>>>>>>>
>>>>>>>>> First of all, re-tuning this is a mmc protocol specific thing
>>>>>>>>> should
>>>>>>>>> be managed from the mmc core, like the approach you have taken in
>>>>>>>>> your
>>>>>>>>> $subject patchset. Second I question whether the timer is useful at
>>>>>>>>> all.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The SD Host Controller Specification does not document another way
>>>>>>>> to do
>>>>>>>> mode 1 re-tuning. The timer is it. Otherwise re-tuning is never
>>>>>>>> done.
>>>>>>>>
>>>>>>>> In the patches I sent, the driver must call mmc_retune_needed() to
>>>>>>>> set
>>>>>>>> host->need_retune = 1 otherwise mmc_retune() does nothing.
>>>>>>>>
>>>>>>>> I would like to extend the model to include transparently re-tuning
>>>>>>>> and
>>>>>>>> re-trying when there is a CRC error, but that is a separate issue,
>>>>>>>> not
>>>>>>>> documented in the spec but recommended by others.
>>>>>>>>
>>>>>>>
>>>>>>> That perfect and in line from what I heard as recommendations from
>>>>>>> memory vendors as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>> How would that work for SDIO? How do you know it is OK to retry SDIO
>>>>>> operations?
>>>>>
>>>>>
>>>>>
>>>>> Retries or error handling, needs to be handled from SDIO func drivers
>>>>> or upper level code. They certainly also need it for other errors,
>>>>> which are not caused by the lack of a re-tune. I believe they exist
>>>>> already.
>>>>>
>>>>> For mmc core point of view, we need to act on SDIO data transfers
>>>>> errors and perform re-tuning for cases when it makes sense.
>>>>>
>>>>> More importantly, using a timer won't make SDIO data transfers error
>>>>> free, since we can still end up needing a re-tune at any point.
>>>>>
>>>>> Still, you do have point for SDIO. Minimizing the number of errors for
>>>>> SDIO could be important, due to that an SDIO func driver may not be
>>>>> able to recover from data errors as smoothly as the mmc block layer
>>>>> can. Thus, a timer could help to improve the situation, but I think it
>>>>> only makes sense in the SDIO case.
>>>>>
>>>>> BTW, what's your experience around SDIO cards supporting SDR104. I
>>>>> have never used such, have you?
>>>>
>>>>
>>>>
>>>> My primary focus in all this discussing is about SDIO cards. The main
>>>> reason being that our 11ac wifi SDIO cards do support SDR104. So the
>>>> brcmfmac driver support SDIO and has retry mechanisms in place. However,
>>>> it may also end-up doing an abort under certain conditions.
>>>>
>>>> You also mentioned using runtime-pm, but how do you deal with func
>>>> drivers not supporting runtime-pm. That is already an issue aka. bug
>>>> right now. Our driver does not support runtime-pm (yet) and we have
>>>> reported issues that host controller does runtime-pm basically killing
>>>> communication between device and func driver.
>>>
>>>
>>
>> Runtime PM is implemented a bit differently between SDIO vs MMC/SD.
>> Your are right.
>>
>> For MMC/SD the mmc block device handles pm_runtime_get|put() in
>> principle per request basis and makes use of the
>> pm_runtime_autosuspend feature. While in the SDIO case, it's entirely
>> up the SDIO func driver to deal with pm_runtime_get|put().
>>
>> So it seems like we can use runtime PM for MMC/SD but not for SDIO. At
>> least not using the SDIO func device.
>>
>>>
>>> Could leave it to the function driver to call mmc_retune_needed().
>>
>>
>> Hmm, the positive side from such approach would be that the SDIO func
>> driver can decide when it's convenient to do a re-tune.
>
>
> I would say "appropriate" instead of "convenient".
>
>> The negative side is that all SDIO func driver would need to care
>> about this. I am not sure we want that.
>
>
> The whole retry handling also seems deferred to the SDIO func driver and the
> same for runtime-pm. As the "retune needed" question would pops up during
> the retry handling it seems not a bad option.

Okay, your argument seems reasonable, let's got for this approach.

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



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux