- 06 Dec, 2012 32 commits
-
-
Abhilash Kesavan authored
Add dt-based retrieval of host sdio pm capabilities. Based on the dt based discovery do a bus init in the resume function. Signed-off-by: Olof Johansson <olofj@chromium.org> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Abhilash Kesavan authored
Add support for optional pm capabilities such as MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ. Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Abhilash Kesavan authored
Add documentation for pm capabilties such as MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ. Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Abhilash Kesavan authored
Fix typo in the synopsis dwmmc controller dt binding filename. Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Kevin Liu authored
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Kevin Liu authored
For regulator vmmc/vmmcq, use voltage range as below 3.3v/3.0v: (2.7v, 3.6v) 1.8v: (1.7v, 1.95v) Original code uses the precise value which may fail in regulator driver if it does NOT support the precise voltage. Signed-off-by: Jialing Fu <jlfu@marvell.com> Signed-off-by: Kevin Liu <kliu5@marvell.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Tony Prisk authored
This patch adds support for the SD/MMC host controller found on Wondermedia 8xxx series SoCs, currently supported under arm/arch-vt8500. A binding document is also included, based on mmc.txt with additional properties. Signed-off-by: Tony Prisk <linux@prisktech.co.nz> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Loic Pallardy authored
RPMB partition is accessing though /dev/block/mmcXrpmb device User callers can read and write entire data frame(s) as defined by JEDEC Standard JESD84-A441, using standard IOCTL interface. Signed-off-by: Alex Macro <alex.macro@stericsson.com> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Krishna Konda <kkonda@codeaurora.org> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Loic Pallardy authored
Provide support for automatically sending Set Block Count (CMD23) messages. Used at least for RPMB support. Signed-off-by: Alex Macro <alex.macro@stericsson.com> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Johan Rudholm <johan.rudholm@stericsson.com> Acked-by: Krishna Konda <kkonda@codeaurora.org> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Loic Pallardy authored
Extend current sysfs access to ext_csd rpmb parameters (RPMB partition size) and rel_sector information. Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Johan Rudholm <johan.rudholm@stericsson.com> Acked-by: Krishna Konda <kkonda@codeaurora.org> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Loic Pallardy authored
Do not scan rpmb partitions for "soft" partitions, since the rpmb partition contains protected data. Silences the following message during boot: mmcblkXRPMB: unknown partition table Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Krishna Konda <kkonda@codeaurora.org> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Loic Pallardy authored
Following JEDEC standard, if the mmc supports RPMB partition, a new interface is created and exposed via /dev/block. Users will be able to access RPMB partition using standard mmc IOCTL commands. Signed-off-by: Alex Macro <alex.macro@stericsson.com> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Johan Rudholm <johan.rudholm@stericsson.com> Acked-by: Krishna Konda <kkonda@codeaurora.org> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Kevin Liu authored
Both of MMC_TIMING_LEGACY and MMC_TIMING_UHS_SDR12 are defined to 0. And ios->timing is set to MMC_TIMING_LEGACY during power up. But set_ios can't distinguish these two timing if host support spec 3.0. Just adjust timing values to be different can resolve this issue without any other impact. Reviewed-by: Girish K S <girish.shivananjappa@linaro.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Kevin Liu authored
Enable the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN since SD_CAPABILITIES_1[15:8](BASE_FREQ) can't get correct base clock value. It returns a fixed pre-set value like 200 on some sdhci-pxav3 based platforms like MMP3 while return 0 on the other sdhci-pxav3 based platforms. So we enable the quirk and get the base clock via function get_max_clock. Also add get_max_clock. Reported-by: Philip Rakity <prakity@marvell.com> Reviewed-by: Philip Rakity <prakity@Marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Lee Jones authored
There are discrepancies with regards to how MMC capabilities are carried throughout the subsystem. Let's standardise them to eliminate any confusion. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Fabio Estevam authored
All MXS users have been converted to device tree and the board files have been removed. No need to keep platform data in the driver. Also move bus_width declaration in the beggining of mxs_mmc_probe() to avoid: 'warning: ISO C90 forbids mixed declarations and code'. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Kyoungil Kim authored
Before this patch, we always used only single sg entry for SDIO transfer. This patch switches to using multiple sg entries. In the case of dwmci, it supports only up to 4KB size per single sg entry. So if we want to transfer more than 4KB, we should send more than 1 command. When we tested before applying this patch, it took around 335 us for 5K(5120) bytes transfer with dwmci controller. After applying this patch, it takes 242 us for 5K bytes. So this patch makes around 38% performance improvement for 5K bytes transfer. If the transfer size is bigger, then the performance improvement ratio will be increased. Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Trey Ramsay authored
There are infinite loops in the mmc code that can be caused by bad hardware. The code will loop forever if the device never comes back from program mode, R1_STATE_PRG, and it is not ready for data, R1_READY_FOR_DATA. A long timeout is added to prevent the code from looping forever. The timeout will occur if the device never comes back from program state or the device never becomes ready for data. It's not clear whether the timeout will do more than log a pr_err() and then start a fresh hang all over again. We may need to extend this patch later to perform some kind of reset of the device (is that possible?) or rejection of new I/O to the device. Signed-off-by: Trey Ramsay <tramsay@linux.vnet.ibm.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Arnd Bergmann authored
The patch "dw_mmc: fix multiple drv_data NULL dereferences" has unfortunately clashed with my "mmc: dw_mmc: constify dw_mci_idmac_ops in exynos back-end" patch, causing new warnings to appear. This should hopefully fix the issue for good. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Ludovic Desroches authored
The at91-mci driver is not needed anymore since the atmel-mci driver now supports all Atmel devices. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Balaji T K authored
MMC debounce clock is applicable only for omap2430, warning message gets printed when enable fails for debounce clock. Remove the get debounce clock failure message as it is noisy for other platforms. Signed-off-by: Balaji T K <balajitk@ti.com> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Daniel Mack authored
Maximum bus frequency can be limited by external circuitry like level shifters etc. Allow passing this value from DT. Signed-off-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Venkatraman S <svenkatr@ti.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Daniel Mack authored
This allows DT-driven board to set up the pin mux only when the driver is in use. Signed-off-by: Daniel Mack <zonque@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Venkatraman S <svenkatr@ti.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Javier Martin authored
When a SD card is initialized some data transfers of 64 and 8 bytes are issued. It seems the DMA has some problems dealing with these kind of "short" transfers, leading sometimes to the SD card not being detected. In order to solve this problem, do not use DMA for transfer sizes lower than the sector size. Signed-off-by: Javier Martin <javier.martin@vista-silicon.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Andy Shevchenko authored
Since v3.2 we have nice macro to define the platform driver's init and exit calls. This patch simplifies the dw_mmc platform driver by using that macro. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Girish K S <girish.shivanajappa@linaro.org> Acked-by: Will Newton <will.newton@imgtec.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Andy Shevchenko authored
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Girish K S <girish.shivananjappa@linaro.org> Acked-by: Will Newton <will.newton@imgtec.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Seungwon Jeon authored
In case both 'req' and 'mq->mqrq_prev->req' are null, there is no request to be processed. That means there is no need to switch buffer. Switching buffer is required only after finishing 'issue_fn'. Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com> Reviewed-by: Per Forlin <per.forlin@stericsson.com> Tested-by: Johan Rudholm <johan.rudholm@stericsson.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Johan Rudholm authored
Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com> Reviewed-by: Philip Rakity <prakity@nvidia.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Kevin Liu authored
The vmmc regulator enable in sdhci_add_host is NOT necessary since it can be enabled during mmc_power_up by function mmc_regulator_set_ocr. And this extra enable will make regulator_enable/regulator_disable unbalanced. Consequently, vmmc can't be disabled during mmc_power_off. Also, if the vqmmc regulator exists, it should be enabled regardless it support 1.8v or not. Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Guennadi Liakhovetski authored
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. Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Tested-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp> Cc: stable@vger.kernel.org Signed-off-by: Chris Ball <cjb@laptop.org>
-
Chris Ball authored
This reverts commit 8464dd52, which was a misapplied debugging version of the patch, not the final patch itself. Signed-off-by: Chris Ball <cjb@laptop.org> Cc: stable@vger.kernel.org
-
Heiko Stübner authored
2abeb5c5 ("Add clk_(enable/disable) in runtime suspend/resume") added the capability to stop the clocks when the device is runtime suspended, but forgot to handle the case of the card-detect using an external gpio. Therefore in the case that runtime-pm is enabled, start the io-clock when a card is inserted and stop it again once it is removed. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Chris Ball <cjb@laptop.org>
-
- 07 Nov, 2012 8 commits
-
-
Seungwon Jeon authored
If host clock is disabled, host cannot detect a card in case of using CD internal for detection. Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Thomas Abraham authored
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Arnd Bergmann authored
The of_device_id match data is now marked as const and must not be modified. This changes the dw_mmc to mark all pointers passing the dw_mci_drv_data or dw_mci_dma_ops structures as const, and also marks the static definitions as const. drivers/mmc/host/dw_mmc-exynos.c: In function 'dw_mci_exynos_probe': drivers/mmc/host/dw_mmc-exynos.c:234:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Thomas Abraham <thomas.abraham@linaro.org> Cc: Will Newton <will.newton@imgtec.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Arnd Bergmann authored
The MODULE_DEVICE_TABLE entry for dw_mci_exynos_match was incorrectly copied from the platform back-end, which causes this error when building the driver as a loadable module: drivers/mmc/host/dw_mmc-exynos.c: At top level: drivers/mmc/host/dw_mmc-exynos.c:226:34: error: '__mod_of_device_table' aliased to undefined symbol 'dw_mci_pltfm_match' This patch fixes the problem by just using the correct string. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Thomas Abraham <thomas.abraham@linaro.org> Cc: Will Newton <will.newton@imgtec.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Chris Ball authored
Commit 473b095a ("mmc: sdhci: fix incorrect command used in tuning") introduced a NULL dereference at resume-time if an SD 3.0 host controller raises the SDHCI_NEEDS_TUNING flag while no card is inserted. Seen on an OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too. Signed-off-by: Chris Ball <cjb@laptop.org> Cc: stable <stable@vger.kernel.org> [3.3+]
-
Kevin Liu authored
There are two problems here: The check for vmmc was printing an unnecessary pr_info() when host->vmmc is NULL. The intent of the check for vqmmc was to only remove UHS if we have a regulator that doesn't support the required voltage, but since IS_ERR() doesn't catch NULL, we were actually removing UHS modes if vqmmc isn't present at all -- since it isn't present for most users, this breaks UHS for them. This patch fixes that UHS regression in 3.7-rc1. Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Bin Wang <binw@marvell.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Russell King - ARM Linux authored
1. Never ever publish a device in the system before it has been setup to a usable state. 2. Unregister the device _BEFORE_ taking away any resources it may be using. 3. Don't check clks against NULL. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Chris Ball <cjb@laptop.org>
-
Guennadi Liakhovetski authored
A recent commit "mmc: sh_mmcif: fix clock management" has introduced a use after free bug in sh_mmcif.c: in sh_mmcif_remove() the call to mmc_free_host() frees private driver data, therefore using it afterwards is a bug. Revert that hunk. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: stable@vger.kernel.org [3.6] Signed-off-by: Chris Ball <cjb@laptop.org>
-