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
