On 27/01/2017 5:12 p.m., Ulf Hansson wrote:
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?
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.
However ERASE_GROUP_DEF also affects the size of write protect groups.
--
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
