Clock selection before switching mode for eMMCs

Clock selection before switching mode for eMMCs

[Eugen.Hristev]

Hello Ulf, Adrian, and anyone interested,

On our AT91 products we have an SD/MMC block with an included DLL that 
does not lock if the SD clock is not configured depending on speed 
modes, like high speed requires 25 Mhz, HS200 requires 100 Mhz, etc.

All the spec and the code configures everything at 400 kHz and then 
moves to high speed, etc. and in the end , the clock is raised.
While this is perfectly fine, on our block we need to raise the clock 
first and change the speed mode after.

Namely, in the function mmc_select_timing , if we call first 
mmc_set_bus_speed then our DLL will lock correctly when selecting the 
mode. If we select the mode first, our clock is stuck.

My question is actually how (if possible)  we could do a quirk in the 
mmc such that our block will work correctly.
So I would need a little guidance about where to place such quirk, if it 
would be accepted or not, and we are forced to be incompatible with the 
linux-mmc sdhci .

I have seen some patches for something similar a few years ago [1] on 
the ML, but they were left floating in the end, so that is why I am 
asking, which would be the proper way to do this.

Thanks !
Eugen

[1] https://patchwork.kernel.org/patch/7127441/

Re: Clock selection before switching mode for eMMCs

[Ulf Hansson]

On Fri, 26 Jun 2020 at 18:00, <Eugen.Hristev@microchip.com> wrote:
>
> Hello Ulf, Adrian, and anyone interested,
>
> On our AT91 products we have an SD/MMC block with an included DLL that
> does not lock if the SD clock is not configured depending on speed
> modes, like high speed requires 25 Mhz, HS200 requires 100 Mhz, etc.
>
> All the spec and the code configures everything at 400 kHz and then
> moves to high speed, etc. and in the end , the clock is raised.
> While this is perfectly fine, on our block we need to raise the clock
> first and change the speed mode after.
>
> Namely, in the function mmc_select_timing , if we call first
> mmc_set_bus_speed then our DLL will lock correctly when selecting the
> mode. If we select the mode first, our clock is stuck.
>
> My question is actually how (if possible)  we could do a quirk in the
> mmc such that our block will work correctly.
> So I would need a little guidance about where to place such quirk, if it
> would be accepted or not, and we are forced to be incompatible with the
> linux-mmc sdhci .
>
> I have seen some patches for something similar a few years ago [1] on
> the ML, but they were left floating in the end, so that is why I am
> asking, which would be the proper way to do this.

I would prefer if this is addressed in the host driver. Typically in
the host's ->set_ios() callback, before you update the clock according
to ios->clock, you can check the ios->timing value. If the conditions
don't allow to update the clock, just defer it to next time when the
->set_ios() callback is being called, likely having the "correct"
ios->timing.

Would that work?

>
> Thanks !
> Eugen
>
> [1] https://patchwork.kernel.org/patch/7127441/

Kind regards
Uffe