Commit Graph

6 Commits

Author SHA1 Message Date
Julia Lawall
2198a64a74 drivers/mmc: correct error-handling code
sdhci_alloc_host returns an ERR_PTR value in an error case instead of NULL.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@match exists@
expression x, E;
statement S1, S2;
@@

x = sdhci_alloc_host(...)
... when != x = E
(
*  if (x == NULL || ...) S1 else S2
|
*  if (x == NULL && ...) S1 else S2
)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Matt Fleming <matt@console-pimps.org>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Cc: Philip Langdale <philipl@overt.org>
Cc: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-07 10:39:56 -07:00
Anton Vorontsov
a9e58f2573 sdhci: get rid of "frequency too high" flood when using eSDHC
Since commit 8dfd0374be ("MMC core: limit
minimum initialization frequency to 400kHz") MMC core checks for minimum
frequency, and that causes following messages flood when using eSDHC
controllers:

  ...
  mmc0: Minimum clock frequency too high for identification mode
  mmc0: Minimum clock frequency too high for identification mode
  ...

The warnings are legitimate, since if we'd use 133 MHz clocks for standard
SDHCI controllers, we'd not able to scale frequency down to 400 kHz.

But eSDHC controllers have a non-standard SD clock management, so we can
divide clock by 256 * 16, not just 256.

This patch introduces get_min_clock() callback for sdhci core and
implements it for sdhci-of driver, and thus fixes the issue.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Matt Fleming <matt@console-pimps.org>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Cc: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-07-29 19:10:36 -07:00
Anton Vorontsov
5fe23c7f51 sdhci: Add support for hosts that are only capable of 1-bit transfers
Some hosts (hardware configurations, or particular SD/MMC slots) may
not support 4-bit bus. For example, on MPC8569E-MDS boards we can
switch between serial (1-bit only) and nibble (4-bit) modes, thought
we have to disable more peripherals to work in 4-bit mode.

Along with some small core changes, this patch modifies sdhci-of
driver, so that now it looks for "sdhci,1-bit-only" property in the
device-tree, and if specified we enable a proper quirk.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
2009-06-21 21:00:59 +02:00
Dave Liu
fbf6a5fcbc sdhci-of: Fix the wrong accessor to HOSTVER register
Freescale eSDHC controller has the special order for
the HOST version register. that is not same as the other's
registers. The address of HOSTVER in spec is 0xFE, and
we need use the in_be16(0xFE) to access it, not in_be16(0xFC).

Signed-off-by: Dave Liu <daveliu@freescale.com>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
2009-06-03 21:56:22 +02:00
Kumar Gala
992697e9b3 sdhci-of: Add fsl,esdhc as a valid compatible to bind against
We plan to use fsl,esdhc going forward as the base compatible so update
the driver to bind against it.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
2009-06-03 21:49:55 +02:00
Anton Vorontsov
3085e9c1b2 mmc: Add OpenFirmware bindings for SDHCI driver
This patch adds a new driver: sdhci-of. The driver is similar to
the sdhci-pci, it contains common probe code, and controller-specific
ops and quirks.

So far there are only Freescale eSDHC ops and quirks.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2009-03-24 21:30:11 +01:00