[PATCH 3/7] ARM: U300: set f_max to 24 MHz for MMCI

[PATCH 3/7] ARM: U300: set f_max to 24 MHz for MMCI

[Linus Walleij]

This employs the frequency setting mechanism introduced to the
MMCI to specify that this system can actually be clocked at 24 MHz.

Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
---
 arch/arm/mach-u300/mmc.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-u300/mmc.c b/arch/arm/mach-u300/mmc.c
index 109f5a6..c1cb977 100644
--- a/arch/arm/mach-u300/mmc.c
+++ b/arch/arm/mach-u300/mmc.c
@@ -101,6 +101,7 @@ int __devinit mmc_init(struct amba_device *adev)
 	 * we have a regulator we can control instead.
 	 */
 	/* Nominally 2.85V on our platform */
+	mmci_card->mmc0_plat_data.f_max = 24000000;
 	mmci_card->mmc0_plat_data.status = mmc_status;
 	mmci_card->mmc0_plat_data.gpio_wp = -1;
 	mmci_card->mmc0_plat_data.gpio_cd = -1;
-- 
1.6.6

[PATCH 3/7] ARM: U300: set f_max to 24 MHz for MMCI

[Russell King - ARM Linux]

On Fri, Feb 19, 2010 at 01:05:31AM +0100, Linus Walleij wrote:
> This employs the frequency setting mechanism introduced to the
> MMCI to specify that this system can actually be clocked at 24 MHz.
> 
> Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
> ---
>  arch/arm/mach-u300/mmc.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-u300/mmc.c b/arch/arm/mach-u300/mmc.c
> index 109f5a6..c1cb977 100644
> --- a/arch/arm/mach-u300/mmc.c
> +++ b/arch/arm/mach-u300/mmc.c
> @@ -101,6 +101,7 @@ int __devinit mmc_init(struct amba_device *adev)
>  	 * we have a regulator we can control instead.
>  	 */
>  	/* Nominally 2.85V on our platform */
> +	mmci_card->mmc0_plat_data.f_max = 24000000;

I bet setting this without DMA support leads to overruns/underruns on
the interface.  That's why MMCI has a low default - to ensure that PIO
mode can keep up with the data transfers; the low maximum isn't because
of something to do with ARM platforms.

[PATCH 3/7] ARM: U300: set f_max to 24 MHz for MMCI

[Linus Walleij]

[Russell]
> On Fri, Feb 19, 2010 at 01:05:31AM +0100, Linus Walleij wrote:
> > @@ -101,6 +101,7 @@ int __devinit mmc_init(struct amba_device *adev)
> >  	 * we have a regulator we can control instead.
> >  	 */
> >  	/* Nominally 2.85V on our platform */
> > +	mmci_card->mmc0_plat_data.f_max = 24000000;
> 
> I bet setting this without DMA support leads to overruns/underruns on
> the interface.

Actually no, not on the U300. On the RealView etc, yes.

Because we have this (see mmci_set_clkreg()):

if (host->hw_designer == AMBA_VENDOR_ST)
	clk |= MCI_FCEN; /* Bug fix in ST IP block */

This enables HW flow control on the block, and holds back
reads/writes so it doesn't over/underruns.

We experienced the problem years ago, and reported to
ST Microelectronics, who fixed it in the next hardware
revision. All present U300 platforms have this fixed.
But the clk framework restricts it to 18.9 MHz.

Linus Walleij

[PATCH 3/7] ARM: U300: set f_max to 24 MHz for MMCI

[Russell King - ARM Linux]

On Mon, Feb 22, 2010 at 09:42:57PM +0100, Linus Walleij wrote:
> Actually no, not on the U300. On the RealView etc, yes.
> 
> Because we have this (see mmci_set_clkreg()):
> 
> if (host->hw_designer == AMBA_VENDOR_ST)
> 	clk |= MCI_FCEN; /* Bug fix in ST IP block */
> 
> This enables HW flow control on the block, and holds back
> reads/writes so it doesn't over/underruns.

Pierre used to argue that stopping the clock to the card was a bad
thing, which is probably based on his experience dealing with SD/SDIO
cards - so really the overrun/underrun problem is not a bug with the
hardware.

I had a MMC card completely destroyed by the PXA MCI hardware (to the
point that it lost its identification), and never worked out why - I
do seem to remember that the spec does not permit the stopping of the
card clock with a command in progress.  Since that time I vowed to
stay clear of the MMC/SD/SDIO crap again - in my view the whole design
is far too fragile and implementations on both sides are too buggy for
safe and reliable use.

I'm not sure at the moment where we go with these DMA patches - I was
working on AACI to add DMA support there, until the ALSA developers
totally and utterly crapped my work there by making changes to the
driver behind my back - I've not got the motivation to undo all the
shite they changed to get things back into a reasonable shape yet.

So I'm just going to sit on the AMBA DMA stuff for the time being.

[PATCH 3/7] ARM: U300: set f_max to 24 MHz for MMCI

[Linus Walleij]

[Russell]

> Pierre used to argue that stopping the clock to the card was a bad
> thing, which is probably based on his experience dealing with SD/SDIO
> cards - so really the overrun/underrun problem is not a bug with the
> hardware.

Yep I heard from earlier discussions, and it's probably not a good
idea at all on SDIO cards atleast.

I don't know how this hardware solution actually works, if it's
really like they're gating the clock, could be something else,
like NACK:in all transactions or whatever the MMC/SD spec permits,
could even be a hidden deep buffer. I will try to dig out the details.

In newer designs like the U8500 we have the PIO IRQ removed even,
so they can only be used without DMA.

> So I'm just going to sit on the AMBA DMA stuff for the time being.

OK no hurries, I do see the problems :-/

If a generic PrimeCell DMA doesn't work out, we will have to fork
the driver instead, since we cannot even use it with the U8500
without DMA support, perhaps this is just as good anyway since
we wouldn't be disturbing RealView etc with our patches. But
it'll lead to some code duplication.

Linus Walleij

[PATCH 3/7] ARM: U300: set f_max to 24 MHz for MMCI

[Russell King - ARM Linux]

On Wed, Feb 24, 2010 at 03:35:46PM +0100, Linus Walleij wrote:
> If a generic PrimeCell DMA doesn't work out, we will have to fork
> the driver instead, since we cannot even use it with the U8500
> without DMA support, perhaps this is just as good anyway since
> we wouldn't be disturbing RealView etc with our patches. But
> it'll lead to some code duplication.

Versatile and Realview both have DMA infrastructure based around the
PL080 and a routing selector for the DMA signals.  However, no one
has yet come up with a suitable way to deal with this yet...

[PATCH 3/7] ARM: U300: set f_max to 24 MHz for MMCI

[Linus Walleij]

[Russell]

> Versatile and Realview both have DMA infrastructure based around the
> PL080 and a routing selector for the DMA signals.  However, no one
> has yet come up with a suitable way to deal with this yet...

OK if there is anything more I can do to improve the example
with PL180 + DMA engine and the extra interface from <linux/amba/dma.h>
I'm willing to give it a spin. I don't have a RealView/Versatile readily
available so sadly I cannot experiment on these (and they're not
cheap either, I'm told, so it's not like I could walk over to
the shopping mall and buy one).

I can try to make a PL011 and/or PL022 DMA extension as well just as
an extended proof of concept, would this help?

Yours,
Linus Walleij

[PATCH 3/7] ARM: U300: set f_max to 24 MHz for MMCI

[Linus Walleij]

OK I have now investigated this MMCI HW flow control mentioned
earlier (Dan, this may be outside your interests, sorry in that
case):

> > if (host->hw_designer == AMBA_VENDOR_ST)
> > 	clk |= MCI_FCEN; /* Bug fix in ST IP block */
> > 
> > This enables HW flow control on the block, and holds back
> > reads/writes so it doesn't over/underruns.
>
> Pierre used to argue that stopping the clock to the card was a bad
> thing, which is probably based on his experience dealing with SD/SDIO
> cards - so really the overrun/underrun problem is not a bug with the
> hardware.

Yep this is achieved by gating the clocks to the card indeed.
It will gate all clocks to the card, not just one, so MCIFBCLK
(i.e. the feedback clock from the card), MCICLKOUT (output to
the feedback loop) and MCICLK (main card clock) are all gated.

This has been in widespread use on the U300 platform under another
OS however, and no big problems have been reported. I believe this
is because we only have this platform fitted with uSD-cards in
practice, and those are late to the MMC/SD-show and may thus be
tolerant to this behaviour, something that may not apply to the
MMC cards of old times.

Another place where we use PL180 is with eMMC:s and here we
know the exact card in use, and we know that it will tolerate
this behaviour.

So for us this frequency and HW gating seems to be acceptable
in practice though in theory we could solder in an MMC card holder
to the PL180.

Linus Walleij