Re: [PATCH v2 2/2] mmc: mediatek: extend number of tuning steps

[AngeloGioacchino Del Regno]

Il 28/11/23 10:38, Axe Yang (杨磊) ha scritto:
> > On Tue, 2023-11-28 at 09:53 +0100, AngeloGioacchino Del Regno wrote:
> > Il 28/11/23 08:01, Axe Yang ha scritto:
> > > Previously, during the MSDC calibration process, a full clock cycle
> > > actually not be covered, which in some cases didn't yield the best
> > > results and could cause CRC errors. This problem is particularly
> > > evident when MSDC is used as an SDIO host. In fact, MSDC support
> > > tuning up to a maximum of 64 steps, but by default, the step number
> > > is 32. By increase the tuning step, we are more likely to cover
> > > more
> > > parts of a clock cycle, and get better calibration result.
> > >
> > > To illustrate, when tuning 32 steps, if the obtained window has a
> > > hole
> > > near the middle, like this: 0xffc07ff (hex), then the selected
> > > delay
> > > will be the 6 (counting from right to left).
> > >
> > > (32 <- 1)
> > > 1111 1111 1100 0000 0000 0111 11(1)1 1111
> > >
> > > However, if we tune 64 steps, the window obtained may look like
> > > this:
> > > 0xfffffffffffc07ff. The final selected delay will be 44, which is
> > > safer as it is further away from the hole:
> > >
> > > (64 <- 1)
> > > 1111 ... (1)111 1111 1111 1111 1111 1100 0000 0000 0111 1111 1111
> > >
> > > In this case, delay 6 selected through 32 steps tuning is obviously
> > > not optimal, and this delay is closer to the hole, using it would
> > > easily cause CRC problems.
> > >
> > > You will need to configure property "mediatek,tuning-step" in MSDC
> > > dts node to 64 to extend the steps.
> >
> > If we can run 64 tuning steps, why should we run 32?
> >
> > Why isn't it just better to *always* run 64 tuning steps, on SoCs
> > supporting that?
> >
> > Thanks,
> > Angelo
>
> Hi Angelo,
>
> That is a good question. The benefit of preserving 32 steps tuning is
> that it can save time in certain scenarios.
>
> On some platforms, when the delay selected through 64 steps tuning is
> very close to that chosen through 32 steps, we can reduce the tuning
> step from 64 to 32. This can save time sending the tuning block
> commands.
>
> Thus using 32 steps tuning can save kernel boot up time.
>
> Another case where time can be saved is when accessing the RPMB
> partition of eMMC. Each time switch to RPMB partition, there is a
> retune action, causing a certain drop in performance. If we are certain
> that the results of 32 steps tuning are usable and we use it, this can
> in a sense also guarantee performance when accessing the RPMB
> partition.

Thanks for this explanation! Though, I have some more questions...

...regarding boot up time, how much time are we talking about?

I'm asking because while now I see - and agree - on using 32-steps tuning
on eMMC to guarantee performance during RPMB access, as far as I know,
there is no RPMB partition on SD/MicroSD cards (and, of course, SDIO devices).

If the boot performance impact isn't big, as in, up to ~100 milliseconds is
not big at all (especially with async probe!), we can definitely avoid the
addition of a devicetree property for 32-steps tuning, hence use a dynamic
selection strategy such that:
 - On eMMC devices, always perform 32-steps tuning (hence no boot delay)
 - On SD cards and SDIO, always perform 64-steps tuning

Cheers,
Angelo