Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote on 2014/05/05 22:50:39:
>
> On 5 May 2014 18:55, Joakim Tjernlund <joakim.tjernlund@xxxxxxxxxxxx>
wrote:
> > I got a Micron eMMC 4.41 memory and I am trying to use the TRIM
function.
> > my EXT_CSD_TRIM_MULT is 15 which gets me a tmo of 15*300=4500 ms
> > Then in mmc_calc_max_discard() I have:
> > max_discard = mmc_do_calc_max_discard(card, MMC_ERASE_ARG);
> > if (mmc_can_trim(card)) {
> > max_trim = mmc_do_calc_max_discard(card,
MMC_TRIM_ARG);
> > if (max_trim < max_discard)
> > max_discard = max_trim;
> > } else if (max_discard < card->erase_size) {
> > max_discard = 0;
> > }
> > pr_debug("%s: calculated max. discard sectors %u for timeout
%u
> > ms\n",
> > mmc_hostname(host), max_discard,
host->max_busy_timeout);
> > Now mmc_do_calc_max_discard(card, MMC_TRIM_ARG) returns 0 because the
> > initial trim
> > timeout is so high, 4500 ms:
> > mmc0: calculated max. discard sectors 0 for timeout 2684 ms
> >
> > How is this supposed to work?
>
> This piece of code in the mmc core/block layer is somewhat broken :-(
:) good to know. I got the impression that it is the eMMC tmo spec that
is broken. How can TRIM have 4.5 s tmo when ERASE is way, way below that?
>
> For 3.15 we merged quite some patches to fixup the hardware busy
> detection mechanism supported by some host drivers/controllers.
> Trim/erase may utilize hardware busy detections, it's therefore I
> gives you this background.
I did browse the linus tree but I didn't really see this, but I am new to
MMC
so I don't really know what to look for.
>
> Now, those fixes did not mean any improvements immediately for
> erase/trim, but made some preparations for us to fix it. :-) I have it
> on the top of my mmc-TODO list - that's all I can give you sorry. :-)
Top of mmc TODO list is great( I hope you don't have several TODO lists :)
>
> Anyway, what host driver / controller are you using?
Freescale's esdhc driver/controller for P2040. This controller is
compliant to eMMC 4.2 but I don't think that should be a problem?
As far as I can tell a 4.2 controller should be able to drive a 4.5 eMMC
memory without loss of 4.5 functionality sans the new 4.5 speeds, do you
agree?
>
> Kind regards
> Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
