* Clock selection before switching mode for eMMCs
@ 2020-06-26 16:00 Eugen.Hristev
2020-07-07 7:14 ` Ulf Hansson
0 siblings, 1 reply; 2+ messages in thread
From: Eugen.Hristev @ 2020-06-26 16:00 UTC (permalink / raw)
To: linux-mmc, ulf.hansson, adrian.hunter
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/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Clock selection before switching mode for eMMCs
2020-06-26 16:00 Clock selection before switching mode for eMMCs Eugen.Hristev
@ 2020-07-07 7:14 ` Ulf Hansson
0 siblings, 0 replies; 2+ messages in thread
From: Ulf Hansson @ 2020-07-07 7:14 UTC (permalink / raw)
To: Eugen Hristev; +Cc: linux-mmc, Adrian Hunter
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-07-07 7:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-26 16:00 Clock selection before switching mode for eMMCs Eugen.Hristev
2020-07-07 7:14 ` Ulf Hansson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.