Messages in this thread | | | From | Ulf Hansson <> | Date | Fri, 27 Jan 2017 16:12:24 +0100 | Subject | Re: [PATCH v5 06/12] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality |
| |
On 26 January 2017 at 13:39, Adrian Hunter <adrian.hunter@intel.com> wrote: > On 26/01/17 12:50, Ulf Hansson wrote: >> On 11 January 2017 at 18:19, Gregory CLEMENT >> <gregory.clement@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?
Kind regards Uffe
| |