Haijun Zhang [Tue, 4 Dec 2012 02:41:28 +0000 (10:41 +0800)]
mmc: eSDHC: Recover from ADMA errors
A-003500: False ADMA Error might be reported when ADMA is used for
multiple block read command with Stop at Block Gap. If PROCTL[SABGREQ]
is set when the particular block's data is received by the System side
logic before entire block (with CRC) data is received by the SD side
logic, and also if ADMA descriptor line is fetched at the same time,
then DMA engine might report false ADMA error. eSDHC might not be able
to Continue (PROCTL[CREQ]=1) after Stop at Block Gap.
This issue will impact the eSDHC IP VVN2.3.
Signed-off-by: Haijun Zhang <Haijun.Zhang@freescale.com> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by: Chris Ball <cjb@laptop.org>
Jaehoon Chung [Thu, 8 Nov 2012 08:35:29 +0000 (17:35 +0900)]
mmc: dw_mmc: relocate where dw_mci_setup_bus() is called from
To ensure the stable clock need to enable before set the
DW_MMC_CARD_NEED_INIT flag. If set DW_MMC_CARD_NEED_INIT flag,
wait for 80-clock before first command after power-up.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Seungwon Jeon <tgih.jun@samsung.com> Acked-by: Will Newton <will.newton@imgtec.com> Signed-off-by: Chris Ball <cjb@laptop.org>
Al Cooper [Fri, 30 Nov 2012 15:53:35 +0000 (10:53 -0500)]
mmc: Limit MMC speed to 52MHz if not HS200
If "caps2" host capabilities does not indicate support for MMC
HS200, don't allow clock speeds >52MHz. Currently, for MMC, the
clock speed is set to the lesser of the max speed the eMMC module
supports (card->ext_csd.hs_max_dtr) or the max base clock of the
host controller (host->f_max based on BASE_CLK_FREQ in the host
CAPS register). This means that a host controller that doesn't
support HS200 mode but has a base clock of 100MHz and an eMMC module
that supports HS200 speeds will end up using a 100MHz clock.
Signed-off-by: Al Cooper <alcooperx@gmail.com> Signed-off-by: Chris Ball <cjb@laptop.org>
mmc: sh_mmcif: remove unneeded clock connection ID
MMCIF only uses one clock, all ARM and SuperH platforms register MMCIF
clock lookup entries with no connection ID, hence it can be dropped in
the driver too.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Chris Ball <cjb@laptop.org>
mmc: sh_mobile_sdhi: remove unneeded clock connection ID
SDHI only uses one clock, all ARM and SuperH platform register SDHI clock
lookup entries with no connection ID, hence it can be dropped in the
driver too.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Chris Ball <cjb@laptop.org>
During its probing the SDHI driver prints out the clock frequency, but
does it wrongly, always reporting 0Hz. Use the MMC host frequency value
to fix this issue.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Chris Ball <cjb@laptop.org>
Daniel Drake [Sun, 25 Nov 2012 18:02:54 +0000 (13:02 -0500)]
mmc: dt: add no-1-8-v device tree flag
The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
capable, and it truthfully reports so in its capabilities. This
alternate voltage is used for driving new "UHS-I" SD cards at their
full speed.
However, what the controller doesn't know is that the motherboard
physically doesn't have a 1.8v supply available, so attempting to
switch to the 1.8v level will result in a situation that cannot be
recovered from without physically replugging the SD card.
Add a device tree flag that can be used on systems like these,
and hook it up to the equivalent SDHCI quirk.
Signed-off-by: Daniel Drake <dsd@laptop.org> Reviewed-by: Philip Rakity <prakity@nvidia.com> Signed-off-by: Chris Ball <cjb@laptop.org>
Daniel Drake [Sun, 25 Nov 2012 18:01:19 +0000 (13:01 -0500)]
mmc: sdhci: add quirk for lack of 1.8v support
The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
capable, and it truthfully reports so in its capabilities. This
alternate voltage is used for driving new "UHS-I" SD cards at their
full speed.
However, what the controller doesn't know is that the motherboard
physically doesn't have a 1.8v supply available.
Add a quirk so that systems such as this one can override disable
1.8v support, adding support for UHS-I cards (by running them at
3.3v).
This avoids a problem where the system would first try to run the
card at 1.8v, fail, and then not be able to fully reset the card
to retry at the normal 3.3v voltage.
This is more appropriate than using the MISSING_CAPS quirk, which
is intended for cases where the SDHCI controller is actually lying
about its capabilities, and would force us to somehow override both
caps words from another source.
Signed-off-by: Daniel Drake <dsd@laptop.org> Reviewed-by: Philip Rakity <prakity@nvidia.com> Signed-off-by: Chris Ball <cjb@laptop.org>
mmc: sh-mmcif: avoid oops on spurious interrupts (second try)
On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
interrupts without any active request. To prevent the Oops, that results
in such cases, don't dereference the mmc request pointer until we make
sure, that we are indeed processing such a request.
Suspend methods provided by SDIO drivers are not supposed to be called by
the PM core. Instead, when the SDIO core gets to suspend a device's
ancestor, it calls the device driver's suspend routine. However, the PM
core executes suspend callback routines directly for device drivers whose
bus types don't provide suspend callbacks. In consequece, because the
SDIO bus type doesn't provide a suspend callback, the SDIO drivers'
suspend routines will be executed by the PM core (which shouldn't
happen).
To prevent this from happening, add empty system suspend/resume callbacks
for the SDIO bus type.
An analogous change had been made already by commit (e841a7c mmc: sdio:
Use empty system suspend/resume callbacks at the bus level), but then it
was reverted inadvertently by commit (d8e2ac3 mmc: sdio: Fix PM_SLEEP
related build warnings) that attempted to fix build warnings introduced
by commit e841a7c.
Reported-by: NeilBrown <neilb@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
Viresh Kumar [Thu, 8 Nov 2012 15:09:10 +0000 (20:39 +0530)]
mmc: sdhci-spear: Don't call clk_{un}prepare() in suspend/resume
clk_{un}prepare is mandatory for platforms using common clock
framework. Because for SPEAr we don't do anything in clk_{un}prepare()
calls, just call them once in probe/remove.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
Tomasz Figa [Sun, 25 Nov 2012 20:40:44 +0000 (15:40 -0500)]
mmc: host: sdhci-s3c: Use devm_gpio_request to request GPIOs
The set of GPIO pins used by sdhci-s3c driver varies between
configurations, such as card detect method, pinctrl availability, etc.
This overly complicates the code requesting and freeing GPIO pins, which
must check which pins are used, when freeing them.
This patch modifies the sdhci-s3c driver to use devm_gpio_request to
free requested pins automatically after unbinding the driver.
Signed-off-by: Tomasz Figa <t.figa@samsung.com> Acked-by: Thomas Abraham <thomas.abraham@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
Jerry Huang [Fri, 23 Nov 2012 09:25:03 +0000 (17:25 +0800)]
mmc: sdhci-of-esdhc: support command with busy response expecting for TC
The IP versions older than 2.3 didn't support the command with busy response
which expect for TC bit set. But after the VVN2.3, eSDHC IP has supported it.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> Signed-off-by: Chris Ball <cjb@laptop.org>
Tushar Behera [Tue, 20 Nov 2012 04:11:53 +0000 (09:41 +0530)]
mmc: sdhci-s3c: Use NULL instead of 0 for pointers
The third argument for of_get_property() is a pointer, hence pass
NULL instead of 0.
Fixes the following sparse warning:
sdhci-s3c.c:452:48: warning: Using plain integer as NULL pointer
sdhci-s3c.c:457:52: warning: Using plain integer as NULL pointer
Signed-off-by: Tushar Behera <tushar.behera@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
prepare() is supposed to prevent new children from being registered.
On the MMC subsystem, children (new cards) registration starts with
the card detect IRQ.
Move card detect IRQ disabling to prepare() so that no new cards
will be registered while we're trying to suspend.
Likewise, move card detect IRQ enabling to complete() so we only
try to register new children after our MMC IP is back up.
Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Venkatraman S <svenkatr@ti.com> Signed-off-by: Chris Ball <cjb@laptop.org>
projects / karo-tx-linux.git / log