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

On 26 January 2017 at 13:39, Adrian Hunter [off-list ref] wrote:

On 26/01/17 12:50, Ulf Hansson wrote:

quoted

On 11 January 2017 at 18:19, Gregory CLEMENT
[off-list ref] wrote:

quoted

+                       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