[2/4] mmci: adjust calculation of f_min

Commit Message

Linus Walleij June 28, 2011, 7:57 a.m. UTC

From: Ulf Hansson <[e-mail]>

For the st_clkdiv variant f_min is too low for practical cases,
there is a heuristic calculation that appear to set the min
frequency to mclk rounded up with 512, for our practical use
cases dividing by 257 gives a reasonable floor value on the
ST Micro version of the clock divider.

Signed-off-by: Ulf Hansson <[e-mail]>
Reviewed-by: Sebastian Rasmussen <[e-mail]>
[Use DIV_ROUND_UP to clarify elder code]
Signed-off-by: Linus Walleij <[e-mail]>
---
 drivers/mmc/host/mmci.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Comments

Russell King - ARM Linux July 5, 2011, 11:20 a.m. UTC | #1

On Tue, Jun 28, 2011 at 09:57:33AM +0200, Linus Walleij wrote:
> From: Ulf Hansson <[e-mail]>
> 
> For the st_clkdiv variant f_min is too low for practical cases,
> there is a heuristic calculation that appear to set the min
> frequency to mclk rounded up with 512, for our practical use
> cases dividing by 257 gives a reasonable floor value on the
> ST Micro version of the clock divider.

The only requirement with f_min is that the hardware is capable of
producing a clock at that rate.  Having it smaller than 'practical'
is not a problem, and may help some cards be detected.

The core tries clocks at 400kHz, 300, 200 and 100kHz during probe,
and that's the lowest frequency that will be attempted (provided
the card doesn't actualy say it wants something slower.)

So unless there is a reason not to (eg, divisors above 257 are invalid)
its better to leave it as is.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Linus Walleij July 7, 2011, 8:22 p.m. UTC | #2

2011/7/5 Russell King - ARM Linux <[e-mail]>:
> On Tue, Jun 28, 2011 at 09:57:33AM +0200, Linus Walleij wrote:
>> From: Ulf Hansson <[e-mail]>
>>
>> For the st_clkdiv variant f_min is too low for practical cases,
>> there is a heuristic calculation that appear to set the min
>> frequency to mclk rounded up with 512, for our practical use
>> cases dividing by 257 gives a reasonable floor value on the
>> ST Micro version of the clock divider.
>
> The only requirement with f_min is that the hardware is capable of
> producing a clock at that rate.  Having it smaller than 'practical'
> is not a problem, and may help some cards be detected.

Sorry the changelog is confused. What we're doing is just obey
the maximum clockdivider as seen in mmci_set_clkreg().

It's host->cclk = host->mclk / (clk + 2); for the ST version, and
since the maximum divider in hardware is 255 this becomes
257, so we cannot divide the frequency with anything lower
than 257.

This should also be DIV_ROUND_UP() though, I'm fixing a new
patch.

> So unless there is a reason not to (eg, divisors above 257 are invalid)
> its better to leave it as is.

Above 257 is indeed invalid on ST variants, as above 512 is on
ARM variants.

Thanks,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index fe14072..c73d054 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1063,7 +1063,10 @@  static int __devinit mmci_probe(struct amba_device *dev,
 	}
 
 	mmc->ops = &mmci_ops;
-	mmc->f_min = (host->mclk + 511) / 512;
+	if (variant->st_clkdiv)
+		mmc->f_min = host->mclk / 257;
+	else
+		mmc->f_min = DIV_ROUND_UP(host->mclk, 512);
 	/*
 	 * If the platform data supplies a maximum operating
 	 * frequency, this takes precedence. Else, we fall back