We don't need to change the SDHCI_SDIO_IRQ_ENABLED flag when we're
merely receiving an interrupt - IRQ handling thread in the MMC core
will either re-enable or disable the interrupt via the enable_sdio_irq
callback, which will update this status appropriately.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
sdhci interrupt handling is a mess; there is a lot of code doing very
similar things. Let's clean this up a bit:
1. set's clear down cmd, data and bus power interrupts in one go - we're
always going to handle these.
2. use a do { } while () loop for looping while there are pending
interrupts.
3. group clearing of bits in intmask into one place.
This results in the code becoming simpler and easier to read.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Rather than the SDIO support spawning it's own thread for handling card
interrupts, use the generic IRQ infrastructure for this, triggering it
from the host interface's interrupt handling directly.
This avoids a race between the parent thread waiting to receive an
interrupt response from the card, and the slow startup from the sdio
irq thread, which can occur as a result of high system load (eg, while
udev is running.)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
[Ulf Hansson] Resolved conflict
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Very minor source and binary size reduction.
Signed-off-by: George Spelvin <linux@horizon.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This eliminates a 1-bit left shift in every single caller,
and makes the inner loop of the CRC computation more efficient.
Renamed crc7 to crc7_be (big-endian) since the interface changed.
Also purged #include <linux/crc7.h> from files that don't use it at all.
Signed-off-by: George Spelvin <linux@horizon.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch removes an unneccesary 1ms mdelay in the HS200 tuning
loop, called 40 times per retuning. Currently this causes a latency
of >40ms on any emmc accesses triggering wake from runtime PM,
which can occur for a significant portion of reads on a mostly idle system.
The delay is left in place for SD Cards, which use
MMC_SEND_TUNING_BLOCK rather than MMC_SEND_TUNING_BLOCK_HS200.
I'm not able to find evidence that this is required for SD in the
specs I have access to, however this delay has been present from
initial checkin for SD so I have preserved the original behavior for
compatibility.
This has been verified to fix observed glitching on local audio
playback and recording on apps with inbuilt assumptions on storage
latency.
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Callers of mmc_regulator_get_supply could benefit from knowing if either
of the regulators are present but not yet available. Since callers do
not currently examine the return value, modify this function to return
zero or -EPROBE_DEFER if either regulator get returns the same.
Furthermore, since callers check vmmc/vqmmc using IS_ERR and can deal
with absent regulators, switch to devm_regulator_get_optional. This has
the added benefit of allowing this function to behave correctly even in
the !CONFIG_REGULATOR case such that the stub can be removed.
Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
This patch replaces regulator manipulation with
mmc_regulator_get_supply() function from MMC core.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Found using smatch:
drivers/mmc/host/atmel-mci.c:827 atmci_pdc_complete() warn: variable
dereferenced before check 'host->data' (see line 807)
Stop testing host->data as it is not NULL at that point.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
rtsx_usb_sdmmc module uses the LED classdev if available, but the code
failed to consider the situation that it is built-in and the LED classdev is a
module, leading to following linking error:
LD init/built-in.o
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove':
rtsx_usb_sdmmc.c:(.text+0x2a018e): undefined reference to
`led_classdev_unregister'
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe':
rtsx_usb_sdmmc.c:(.text+0x2a197e): undefined reference to
`led_classdev_register'
Fix by excluding such condition when defining macro RTSX_USB_USE_LEDS_CLASS.
Signed-off-by: Roger Tseng <rogerable@realtek.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Return -ENOSYS in get_cd if broken-cd is specified in the device tree.
Commit a91fe279ae (mmc: mxs: use standard flag for broken card
detection) sets MMC_CAP_NEEDS_POLL when broken-cd is specified. This
driver sets this flag unconditionally as it does not support a card
detect interrupt. Instead, broken-cd means that there is no card detect
signal connected.
The mmc core checks the get_cd function return value to determine if a
card is present. Only for a non-zero return value it will attempt to
initialize the card. So retuning -ENOSYS will allow the card to be
initialized.
For comparison, mmc_gpio_get_cd in slot-gpio.c also returns -ENOSYS if
the card detect GPIO is not valid.
Signed-off-by: Daniel Willmann <daniel@totalueberwachung.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
As of commit bcc3e1726d ("mmc: block: Use R1 responses for stop cmds for
read requests"), stop commands for reads do not have MMC_RSP_BUSY set.
In this case we should not wait for a PRG_DONE IRQ after sending the
stop command: it will not get raised when the busy flag is not set,
causing the request to fail with a timeout.
Signed-off-by: Alex Smith <alex.smith@imgtec.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Chris Ball <chris@printf.net>
Cc: James Hogan <james.hogan@imgtec.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Provide the option to configure these speed modes per host,
for those host driver's that can't distinguish this in runtime.
Specially, if host can support HS400, it means that host can also
support HS200.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
This patch adds HS400 mode support for eMMC5.0 device. HS400 mode is high
speed DDR interface timing from HS200. Clock frequency is up to 200MHz
and only 8-bit bus width is supported. In addition, tuning process of
HS200 is required to synchronize the command response on the CMD line
because CMD input timing for HS400 mode is the same as HS200 mode.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: Jackey Shen <jackey.shen@amd.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Current implementation for bus speed mode selection is too
complicated. This patch is to simplify the codes and remove
some duplicate parts.
The following changes are including:
* Adds functions for each mode selection(HS, HS-DDR, HS200 and etc)
* Rearranged the mode selection sequence with supported device type
* Adds maximum speed for HS200 mode(hs200_max_dtr)
* Adds field definition for HS_TIMING of EXT_CSD
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Power class is changed once only after selection of bus modes
including speed and bus-width finishes finally.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Device types which are supported by both host and device can be
identified when EXT_CSD is read. There is no need to check host's
capability anymore.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Timing mode identifier has same role and can take the place
of speed mode. This change removes all related speed mode.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
SDIO controllers found on Marvell Kirkwood SoCs seem to cause a late,
spurious irq although all interrupts have been disabled. This irq
doesn't do any harm, neither to HW nor driver. To avoid some
"unexpected irq" warning later, we workaround above issue by bailing
out of irq handler early, if we didn't expect any.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
mvsdio reports method of card detection with dev_notice, while for
removable cards it may be sane, for non-removable cards it is not.
Also, as the user cannot do anything about it, silence the message
by reducing it from dev_notice to dev_dbg.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
The eMMC signalling voltage is determined by VCCQ which is provided to
the card by the host. Signalling is not required to begin at 3.3v and,
if the host and card both support a particular VCC/VCCQ combination, it
can be used immediately.
In contrast, SD Cards must begin with 3.3v signalling and may switch to
a lower voltage signalling if instructed to do so in CMD11. A message
is required to coordinate this operation because the card only receives
a 3.3v VDD and must know when to use the 1.8v produced by its internal
regulator.
It makes sense for the core to begin with 3.3v signalling but when that
can't be set, 1.8v and 1.2v signalling also should be attempted. This
is especially important when an external regulator with a limited range
is used to supply VCCQ to an eMMC part.
Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Add SD/MMC driver for MOXA ART SoCs.
The "MOXA ART MMC controller" is likely a faraday "ftsdc010",
a controller with support in U-Boot:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/ftsdc010_mci.c
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Realtek USB SD/MMC host driver provides mmc host support based on the
Realtek USB card reader MFD driver.
Signed-off-by: Roger Tseng <rogerable@realtek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
NUM_GPIOS is not used after e19499ae10 ("mmc: sdhci-s3c: let device
core setup the default pin configuration"). Thus remove it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Restore the card-present checking point.
(The following part was removed from commit bf626e5 ("mmc: dw_mmc:
use slot-gpio to handle cd pin")
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Since using the device-tree, didn't use the callback pointer.
So removed the unused callback pointer.
When the set_power callback is used, it should be added in future.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
It's right to check immediately whether host->bus_hz is assigned or not.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
mmc_of_parse() have been already parsed the general capability.
Didn't need to use the local parser.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Replace existing resource handling in the driver with managed
device resource, this ensures more consistent error values and
simplifies error paths.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Remove the option to provide the flags for mmc capabilities as platform
data, enforce it through DT.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Remove the option to provide signal direction configuration and
feeback clock as platform data, enforce it through DT.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This is pure software configuration, which mmci has been supporting for
a while. Let's enable it as default so we can take benefit from it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Let mmci DT parser only handle the specific bindings related to mmci
and extend the DT support by converting to the common mmc DT parser.
While both DT and platform data exist, DT takes precedence. If there
are supplied DT data, the card detect and write protect GPIOS are
enforced to be provided through it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The ST Micro variant supports the option of using a feedback clock signal in
favor of the clockout pin when latching incoming signals on the data bus.
Since this is matter of how pins are being routed we need to provide a new DT
binding to be able to configure this through DT.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Some variants have support for indicating the bus signal directions,
which currently are configured through platform data.
Add corresponding DT bindings to enable us to move away from using the
platform data.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
To avoid duplication of code while handling card detect and write
protect GPIO pins/irqs, let's convert to use the mmc gpio API.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
For CONFIG_PM_SLEEP, the device were always left in full power state
after system suspend.
We solely relied on a power domain to put it into low power state,
which is an unreasonable requirement to put on SOCs to implement.
Especially for those SOCs not supporting power domains at all.
Use pm_runtime_force_suspend|resume() as the system suspend callbacks,
to resolve the issue.
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Convert to the SET_PM_RUNTIME_PM macro while defining the runtime PM
callbacks. This means the callbacks becomes available for both
CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME, which is needed to handle the
combinations of these scenarios.
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In runtime suspended state, we are not expecting IRQs and thus we can
safely mask them, not only for pwrreg_nopower variants but for all.
Obviously we then also need to make sure we restore the IRQ mask while
becoming runtime resumed.
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This reverts commit c42deffd5b.
commit <mmc: rtsx: add support for pre_req and post_req> did use
mutex_unlock() in tasklet, but mutex_unlock() can't be used in
tasklet(atomic context). The driver needs to use mutex to avoid
concurrency, so we can't use tasklet here, the patch need to be
removed.
The spinlock host->lock and pcr->lock may deadlock, one way to solve
the deadlock is remove host->lock in sd_isr_done_transfer(), but if
using workqueue the we can avoid using the spinlock and also avoid
the problem.
Signed-off-by: Micky Ching <micky_ching@realsil.com.cn>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Realtek USB SD/MMC host driver provides mmc host support based on the Realtek
USB card reader MFD driver.
Signed-off-by: Roger Tseng <rogerable@realtek.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
a27fbf2f06 ("mmc: add ignorance case for CMD13 CRC error") produced
a cmd.flags unhandled in realtek pci host driver. This will make MMC
card fail to initialize, this patch is used to handle the new cmd.flags
condition and MMC card can be used.
Signed-off-by: Micky Ching <micky_ching@realsil.com.cn>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
The sdio func device is added to the driver model after the card
device.
This means the sdio func device will be suspend before the card device
and thus resumed after. The consequence are the mmc core don't
explicity need to protect itself from receiving sdio requests in
suspended state. Instead that can be handled from the sdio bus, which
is thus invokes the PM callbacks instead of old dummy function.
In the case were the sdio func driver don't implement the PM callbacks
the mmc core will in the early phase of system suspend, remove the
card from the driver model and thus power off it.
Cc: Aaron Lu <aaron.lu@intel.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Tested-by: xiaoming wang <xiaoming.wang@intel.com>
Tested-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: Chris Ball <chris@printf.net>
