On 26 January 2017 at 13:39, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
> On 26/01/17 12:50, Ulf Hansson wrote:
>> On 11 January 2017 at 18:19, Gregory CLEMENT
>> <gregory.clement@xxxxxxxxxxxxxxxxxx> 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?
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
