On Tue, Mar 27, 2012 at 10:43 AM, Simon Horman [off-list ref] wrote:

On Mon, Mar 26, 2012 at 03:17:21PM +0900, Magnus Damm wrote:

quoted

On Mon, Mar 26, 2012 at 2:52 PM, Simon Horman [off-list ref] wrote:

quoted

On Mon, Mar 26, 2012 at 02:45:30PM +0900, Yusuke Goda wrote:

quoted

Hi Simon-san, Guennadi-san

(2012/03/26 7:30), Simon Horman wrote:

quoted

On Sat, Mar 24, 2012 at 07:06:31PM +0100, Guennadi Liakhovetski wrote:

quoted

On Wed, 21 Mar 2012, Simon Horman wrote:

quoted

mmc->f_max should be half of the bus clock.
And now that mmc->f_max is not equal to the bus clock the
latter should be used directly to calculate mmc->f_min.

The patch seems correct as it stands, however, looking at it - does anyone
understands why that "close to 400kHz" comment and such a complicated
calculation? Shouldn't it be just host->clk / 512 always? Maybe this
should be a separate patch, so, for this one

Acked-by: Guennadi Liakhovetski <redacted>

Hi Guennadi,

that code seems to date back to the original driver submission
made by Goda-san. I have CCed him as perhaps he recalls why
the code is like it is.

I thought to get closer to 400kHz if possible.
Probably even host->clk / 512 does not have any problem.

Sorry for my ignorance, is ~400kHz desirable for some reason?

The 400kHz frequency is used during initialization of the SD card.
Simply put, the SD frequency starts low out low and is then changed to
something higher depending on the capability of the memory card and
the host controller. Please have a look at the simplified SD
specification for more details.

Thanks, got it.

Do you have a feeling of if it it worth trying to start with a value close
to 400kHz or if it would be better to simplify the code? I can try and
measure the difference in start up time for particular hardware
combinations, but I'm not sure how far that will get us.

I believe the correct way is to program the hardware to be as close to
400 kHz as possible. I may be wrong, but I guess that slower than 400
kHz is also acceptable during the initial phase, but faster may mean
out of spec. For optimal performance the code may need to be reworked
to support both correct and slow 400 kHz as well as whatever high
frequencies needed for fast transfers. It is easier said than done
though. Whenever the common clock framework is in place then we should
be able to reprogram the parent rate and with that get a wider range
of frequencies compared with today. If this will work or not depends
on the hardware - on some SoCs the parent clock is shared with other
peripherals which means we may not be able to change it during
runtime. Other SoCs have individual clocks tied to each MMC controller
which gives us freedom to change the frequency during runtime.

I would not bother optimizing this unless you have deep knowledge
about a wide range of SoCs including clocks and the MMC controller
hardware. So for now I think it's best to aim for correctness only.

Also, what is correct or not varies with SoC model. Since our MMC
controller drivers run on a wide range of hardware it is important to
compare the MMC portion of the data sheet. So in this particular case
it is a good idea to make sure that whatever frequency limitations
that are present in one SoC is also true on other models.

Cheers,

/ magnus