[PATCH v5 06/12] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality

[Ulf Hansson]

On 28 January 2017 at 09:16, Adrian Hunter <adrian.hunter at intel.com> wrote:
> On 27/01/2017 5:12 p.m., Ulf Hansson wrote:
>>
>> On 26 January 2017 at 13:39, Adrian Hunter <adrian.hunter at intel.com>
>> wrote:
>>>
>>> On 26/01/17 12:50, Ulf Hansson wrote:
>>>>
>>>> On 11 January 2017 at 18:19, Gregory CLEMENT
>>>> <gregory.clement at free-electrons.com> wrote:
>>>>>
>>>>> +                       priv->init_card_type = MMC_TYPE_MMC;
>>>>> +                       mmc->caps |= MMC_CAP_NONREMOVABLE;
>>>>> +
>>>>> +                       /*
>>>>> +                        * Force to clear BUS_TEST to
>>>>> +                        * skip bus_test_pre and bus_test_post
>>>>> +                        */
>>>>> +                       mmc->caps &= ~MMC_CAP_BUS_WIDTH_TEST;
>>>>> +                       mmc->caps2 |= MMC_CAP2_HC_ERASE_SZ |
>>>>
>>>>
>>>> This cap is a bit strange. It was added several years ago by Adrian
>>>> Hunter, but I am wondering about the reason to why it's needed.
>>>>
>>>
>>> MMC_CAP2_HC_ERASE_SZ relates to EXT-CSD ERASE_GROUP_DEF.
>>>
>>> I think it was added to enable people to choose whether they wanted a
>>> large
>>> or small erase granularity.  That probably doesn't matter if the card
>>> supports TRIM.
>>>
>>
>> Huh, the erase/trim/discard code in the mmc core is really hairy. :-)
>>
>> In mmc_calc_max_discard() the following code/comment exists:
>>
>> /*
>>  * Without erase_group_def set, MMC erase timeout depends on clock
>>  * frequence which can change.  In that case, the best choice is
>>  * just the preferred erase size.
>>  */
>> if (mmc_card_mmc(card) && !(card->ext_csd.erase_group_def & 1))
>>      return card->pref_erase;
>>
>>
>> This makes me wonder.
>>
>> So, when we haven't enabled the high capacity erase groups in the
>> EXT_CSD register (ext_csd.erase_group_def), we will use the pref_erase
>> size.
>>
>> In the other case, as when having MMC_CAP2_HC_ERASE_SZ set (which will
>> set ext_csd.erase_group_def),  we will instead  do some calculations
>> to find out the max discards.
>>
>> Are you saying that these calculations doesn't matter much - or are
>> you saying that we always want to do them?
>
>
> No, I was saying that if you have TRIM then TRIM is preferred to ERASE so
> the erase group size does not come into play when discarding, since ERASE
> granularity is erase groups whereas TRIM granularity is sectors.

Right. Thanks for clarifying.

>
> However ERASE_GROUP_DEF also affects the size of write protect groups.

In either case.

What do you think of removing MMC_CAP2_HC_ERASE_SZ? I don't like these
kind of soft polices, it's better if we can decide on a common
behaviour - whatever that is.

Kind regards
Uffe